[llvm-dev] LLDB security and the use of an IPC library

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 27 05:00:14 PDT 2017

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.


More information about the llvm-dev mailing list