[Monotone-devel] Re: encrypted monotone (and digression on

[Graydon Hoare]

Rob Schoening wrote:
> I have a somewhat unrelated question that touches on a more fundamental 
> security issue:
>  
> what is the relative security risk of running netsync on a public port 
> assuming it's running as a non privileged user?  how much of a 
> vulnerability is it for the host that's serving it?

Nobody's shown us exploits yet, but it would be foolish for me to imply 
that none exist or are possible. I can point to a few things that might 
reassure you. Whether they do is another matter.

1. Monotone authenticates users (by RSA-signing a nonce and requesting 
an RSA signature in response) before anything else. One may be able to 
DoS the server (in a CPU sense) if anonymous requests are permitted; if 
you insist on authenticated connections from known clients, this risk is 
reduced.

2. Monotone does ::read() off a network socket and into a fixed-size 
stack buffer. However, it does this in exactly one place (netsync.cc, 
session::read_some()) and always issues the read call for the full 
length of the buffer, starting at its beginning, and never restarts the 
read or tries to mix parsing and reading.

3. That buffer is immediately appended to a heap std::string and data is 
parsed from there using "safer" extractor functions. The extractor 
functions all test the length of every extraction against the string 
length, and assert fatally if they are asked to pass the end of the 
string they're reading from. If there's insufficient data for a complete 
command packet during parsing, we give up and restart parsing from the 
string's beginning next time we receive data.

4. Other major parsing points are basic_io.{cc,hh} and xdelta.cc; it is 
possible that those contain logic that can be tricked into indexing past 
the end of the std::strings they're reading from. I'd be happy to go 
through them with a concerned reader doing an audit / inserting more 
dynamic checks / adding tests that try specific attacks.

5. With the exception of misbehavior in glibc during getaddrinfo() and 
setlocale(), we appear to be valgrind-clean.

6. You should be able to chroot / jail / zone / otherwise sandbox us, so 
long as we can access libstdc++, libc, libnss, and our database. We also 
need to be able to create transient journal files in the directory we 
keep the database in, as part of the page-transaction system in sqlite.

Still, it's a nontrivial program, you're right to be concerned. Even if 
you trust our code, we also inherit the possibility of vulnerabilities 
from sqlite, botan, lua, idna, and boost. We do a fair bit of input 
validation, don't call printf, are careful to avoid malloc/free or use 
of raw pointers, etc. but it's hard to be sure.

-graydon