Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: Bryan Olson (
Date: 08/30/02

From: Bryan Olson <>
Date: Fri, 30 Aug 2002 06:10:33 GMT

Apologies if a very similar post appears. (I'm in ISP hell right now.)

Edward Elliott wrote:
> On Wed, 28 Aug 2002 00:29:10 -0400, Bryan Olson wrote:
>>Edward Elliott wrote:
>> > If you're talking about avoiding buffer overflows, just about any
>> > language with bounds checking should fit the bill. I don't see how
>> > Java has any special protection against race conditions [...]
>> >
>> > What unique features does Java have that "help in writing secure
>> > applications"?
>>In no case does Java punt to undefined behavior. Race conditions can
>>result in non-deterministic behavior, but never arbitrary behavior. It
>>is not the only such language, but bounds-checking and lack of raw
>>pointers are not enough.
> Ok let's add that to the list of features which make Java a good choice
> for secure applications:
> 1. Enforced bounds checking
> 2. No raw pointers
> 3. Synchronized keyword for thread safety
> 4. No undefined behavior
> Any more?
> Let's also make a list of what attacks these features mitigate, and to
> what degree:
> 1. Buffer overflows (completely, barring VM bugs)
> 2. Internal race conditions (somewhat, synchronized must be used
> properly)

Well, I'm not sure of this method of assessment, but I'll try it. I
think we should give more credit to "No undefined behavior".

In theory, undefined behavior is arbitrarily bad - up to what the OS
will let the program do. Practice is, in this case, pretty much the
same. Things like buffer overflows really can, have, and do, allow an
attacker to execute code of his own authorship. The lack of undefined
behavior should "mitigate" *every* attack that can trigger undefined
behavior in other languages.

I'm a long-time security guy, more familiar with writing servers than
GUI's. I think it was the fourth day I was studying Java that I wrote a
server. It had one thread handling 'accept' and launched one per
connect. The connect threads immediately entered a 'try' block, and
returned from it immediately before terminating. Most Java servers are
similar, except they may use one thread per in-progress request, rather
than one per connection.

For a large class of errors, C or C++ will have undefined behavior where
Java (or ML, Python, Lisp, Haskell, Perl, or many others) would allow an
attacker to crash his own connection.

As Oprah would say, "that's huge".


Relevant Pages