On Mon, 9 Oct 1995, Perry E. Metzger wrote: [ I just got Man-On-The-Street'ed by a TV news crew asking my opinion of the OJ Verdict, I'm entitled to a little Side-Bar
Sendmail is about 29K lines of C code -- not significantly larger by my standards -- and has proven nearly impossible to secure.
Hey - but sendmail was designed to be Z-1 secure - formally proven to be unsecurable :-)
taken on an impossible task. Marcus Ranum has noted that you can't trust a program thats bigger than a couple of pages long, and I
For the general case this is true. To be able to trust larger systems, you need to not only be able to trust the individual 2 pagers, but to also be able to show that composing the sub units doesn't lose whatever property you're trying to do. The architecture of the system needs to be designed with this in mind; otherwise reasoning about the composite becomes intractable. There are all sorts of things you can do to make analysis easier - eliminating global state, etc. Retrofitting security or verifiability never works. Distributed co-operative theorem proving, anyone? END-DIGRESSION] Real point of the message: In my previous message, I left out some fundamental parts of the run-time that need to be looked at carefully. The garbage collection needs to be examined carefully. Normally GC algorithms are formally derived, so it's the implementation that needs to be checked for. holes in the GC may be too unpredictable to exploit for anything but core-dumping, especially since java uses a mark-sweep conservative collector. A more promising area of attack might be the Thread system. If the thread system can be confused, it might be possible to have an untrusted app start executing in the context of a trusted thread. This may or may not be exploitable, depending on how much of the untrusted threads context gets held over (call stack, etc), but could be fun if it works. Simon