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