llvm dev - Apr 2017 - LLDB security and the use of an IPC library

LLDB currently uses a client-server architecture.  That appears fine,
but runs into an annoying security problem: other users on the same
machine can connect to the TCP socket and take over LLDB and thus the
user’s system.  This means that LLDB is useless in multiuser
enviromnents on Linux, such as academic computer labs.

The immediate problem can be solved by using either HMAC authentication
of all messages or by using Unix domain sockets.  However, it might be
simpler to use a 3rd party library for the purpose:
https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).

Questions:

- Would you be interested in using SlipRock?

- What features would SlipRock need in order to be useful to you?  In
  particular, do you need an asynchronous API, or is synchronous fine?

- If not, would you be willing to accept patches to fix the existing
bug?

Sincerely,

Demi Obenour

(+LLDB-Dev) most of the LLDB developers hang out there more than on LLVM-Dev.
> On Apr 26, 2017, at 12:26 PM, Demi Marie Obenour via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> LLDB currently uses a client-server architecture.  That appears fine,
> but runs into an annoying security problem: other users on the same
> machine can connect to the TCP socket and take over LLDB and thus the
> user’s system.  This means that LLDB is useless in multiuser
> enviromnents on Linux, such as academic computer labs.
> 
> The immediate problem can be solved by using either HMAC authentication
> of all messages or by using Unix domain sockets.  However, it might be
> simpler to use a 3rd party library for the purpose:
> https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
> 
> Questions:
> 
> - Would you be interested in using SlipRock?
Probably not. Generally we shy away from using third party libraries.
> 
> - What features would SlipRock need in order to be useful to you?  In
>   particular, do you need an asynchronous API, or is synchronous fine?
The biggest thing that I would see as a barrier for us using SlipRock is that it
would have to provide a large advantage in order to justify using it. We
generally don't use middleware libraries that are not readily available on
the platforms that we support, usually either via a package manager or shipping
on the OS.
> 
> - If not, would you be willing to accept patches to fix the existing
> bug?
I was actually looking at this code earlier this week. On OS X we do use Unix
socketpair to construct domain sockets between debugserver and lldb. Presently
lldb-server (the debugserver implementation used everywhere other than OS X)
doesn't support accepting a socket pair, but we can and should fix that.
I've been working recently on making more of LLDB's code properly
configured based on system capabilities rather than hard coded assumptions. This
will make it easier for us to do these kinds of things right in the future.

If you're interested in working on getting lldb-server working with
socketpair we would certainly take the patches, and I'd be happy to provide
review or guidance as needed.

Thanks,
-Chris
> 
> Sincerely,
> 
> Demi Obenour
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 26 Apr 2017, at 20:26, Demi Marie Obenour via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> LLDB currently uses a client-server architecture.  That appears fine,
> but runs into an annoying security problem: other users on the same
> machine can connect to the TCP socket and take over LLDB and thus the
> user’s system.  This means that LLDB is useless in multiuser
> enviromnents on Linux, such as academic computer labs.
> 
> The immediate problem can be solved by using either HMAC authentication
> of all messages or by using Unix domain sockets.  However, it might be
> simpler to use a 3rd party library for the purpose:
> https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
> 
> Questions:
> 
> - Would you be interested in using SlipRock?
A cursory glance at SlipRock raises a few concerns:

- It depends on libsodium (I like libsodium, but it adds another external
dependency).

- It doesn’t appear to have been tested on non-Linux *NIX systems (LLDB is the
default debugger on macOS / iOS, is about to be on FreeBSD, and is used on
NetBSD, OpenBSD and Solaris).  I include build testing in this, as the build
system only looks for sodium.h in the default location on Linux.

- The Windows support is not yet done (at least, there’s no tick in the
‘compiles on Windows’ status item).

- Attempting to compile it on FreeBSD gives 9 warnings and 8 errors, with
several warnings referring to playing fast and loose with pointer aliasing
rules.  This makes me very nervous in code that’s intended for security.

- It uses assert() instead of real error handling, which is inappropriate in a
library, and requires that the file be compiled without -DNDEBUG, which makes it
annoying to integrate into other build systems.

- The APIs appear to be entirely undocumented.

- The error handling does not match the lexical scoping and so is very difficult
to follow (and therefore potentially error prone).  I was unable to run the
static analyser on the code because it doesn’t compile on FreeBSD or macOS.

David

Those are all bu

On Apr 27, 2017 8:00 AM, "David Chisnall" <David.Chisnall at
cl.cam.ac.uk>
wrote:

On 26 Apr 2017, at 20:26, Demi Marie Obenour via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> LLDB currently uses a client-server architecture.  That appears fine,
> but runs into an annoying security problem: other users on the same
> machine can connect to the TCP socket and take over LLDB and thus the
> user’s system.  This means that LLDB is useless in multiuser
> enviromnents on Linux, such as academic computer labs.
>
> The immediate problem can be solved by using either HMAC authentication
> of all messages or by using Unix domain sockets.  However, it might be
> simpler to use a 3rd party library for the purpose:
> https://github.com/DemiMarie/SlipRock (Disclaimer: I wrote SlipRock).
>
> Questions:
>
> - Would you be interested in using SlipRock?
A cursory glance at SlipRock raises a few concerns:

- It depends on libsodium (I like libsodium, but it adds another external
dependency).

I plan on removing this dependency by copying the code.


- It doesn’t appear to have been tested on non-Linux *NIX systems (LLDB is
the default debugger on macOS / iOS, is about to be on FreeBSD, and is used
on NetBSD, OpenBSD and Solaris).  I include build testing in this, as the
build system only looks for sodium.h in the default location on Linux.

Do you know of any ways I can do CI on those systems?  That it fails to
build on any *nix platform (with libsodium installed) is a bug.  I am
working on improving the CMake build system to help with that.


- The Windows support is not yet done (at least, there’s no tick in the
‘compiles on Windows’ status item).

I plan on doing a refactoring that should make that much easier.

- Attempting to compile it on FreeBSD gives 9 warnings and 8 errors, with
several warnings referring to playing fast and loose with pointer aliasing
rules.  This makes me very nervous in code that’s intended for security.

Not following the pointer aliasing rules is definitely a bug.  Would you
mind posting the log?


- It uses assert() instead of real error handling, which is inappropriate
in a library, and requires that the file be compiled without -DNDEBUG,
which makes it annoying to integrate into other build systems.

That’s certainly a bug.  I will fix it.


- The APIs appear to be entirely undocumented.

The documentation is in sliprock.h, but the fact that that is not easy to
find is a bug.


- The error handling does not match the lexical scoping and so is very
difficult a to follow (and therefore potentially error prone).  I was
unable to run the static analyser on the code because it doesn’t compile on
FreeBSD or macOS.

That’s definitely a bug, at least in my opinion.  SlipRock should be very
easy to follow.  I was inspired by the Linux kernel’s “goto fail” but
obviously things didn’t work as expected.


David


Thanks,

Demi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170427/f1a4daad/attachment.html>