According to media reports, an attacker can

  • upload a library to a Samba share and then
  • open a named pipe whose name equals the local path to the uploaded library

to remotely execute the code contained in the library.

How does it work? Is this a "classic" buffer overflow? Or is Samba tricked into executing some legitimate library loading code? If yes, how? Is there something we, as developers, can learn from this? I have checked the usual online resources, but they mainly contain information on how to protect yourself if you are a Samba user.

Trying to find the answer, I have looked at the patch:

--- a/source3/rpc_server/srv_pipe.c
+++ b/source3/rpc_server/srv_pipe.c
@@ -475,6 +475,11 @@ bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
    NTSTATUS status;

+   if (strchr(pipename, '/')) {
+       DEBUG(1, ("Refusing open on pipe %s\n", pipename));
+       return false;
+   }
    if (lp_disable_spoolss() && strequal(pipename, "spoolss")) {
        DEBUG(10, ("refusing spoolss access\n"));
        return false;

But, apparently, the patch just adds additional validation and does not show the "juicy part" where the malicious library is loaded.


1 Answer 1


It would be easier if you can analyse the source of the exploit. You can find it here: https://github.com/omri9741/cve-2017-7494

From what can I see it seems Samba just loads the SO and executes it without need of any buffer overflow. Have no idea why such thing is over there but it has probably something to do with RPC over 445/TCP.


Yep. So I went bit deep to it and its really related to IPC/RPC. It seems that you was able to open any .so file under specific conditions over named pipes. Of course, only trusted modules should be allowed and not those uploaded by anybody so I think they mainly fixed from where the modules could be loaded.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .