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

[jcrisp]

I believe a company called Fortify will allow you to run their security
validation tool (DFA style expert system) against open source code for
free. If I remember properly they found several exploitable issues in the
Kernel.

Might be worth a look.

Joel

> 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
>
>
>
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel
>
>