Re: Samba, Google, and The Audacity of Hope

[dominique.brezinski () gmail com]

Sorry for the top post...too difficult to quote from a blackberry.

I gave a presentation at black hat Tokyo a few years ago on security of interpreted languages and the interpreter as 
attack surface that has to be taken into account for certain applications.

I do a lot more ruby stuff than python, so I took a quick look, as did John McDonald, and we found a few int overflows 
in the first few minutes. It seems that the issue of interpreter robustness is just about to break into the mainstream 
consciousness of security folks, but to some degree these issues have been in small-scale discussions for years now.

It sounds like the python guys are more responsive and open than the ruby core community. I had a lot of problems 
trying to discuss the underlying issues with core ruby developers. They were quick to try to shut me up and out of 
their little world. I hope that changes in the future.

Cheers,
Dom 
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: jf <jf () danglingpointers net>

Date: Sat, 12 Apr 2008 00:41:18 
To:Dave Aitel <dave () immunityinc com>
Cc:dailydave () lists immunityinc com
Subject: Re: [Dailydave] Samba, Google, and The Audacity of Hope


> I think launching the Google Application Engine is pretty much an
> audacity of hope kind of event - the zlib bug in Python on the day it
> came out is just the tip of the tip of the iceberg as far as that sort
> of bug goes. Did they really think you can sandbox someone inside
> cPython by removing local file access and the socket module? Perhaps
> Guido sat down and audited it for bugs and just missed one.

The thing is, people don't seem to recognize the interpreter itself as
attack surface for some reason-- we seem to neglect to recognize that
these languages are just C programs, complete with all of its flaws. They
come with their own metadata, their own callstacks, et cetera and all of
the protections we currently have in place are designed to stop me from
attacking the processors metadata-- if I find an overflow in Python and
attack a PyFrameObject and return into Python bytecode, does your NX bit
still help? How effective is ASLR? et cetera.

When you have a heap overflow in Python, you can potentially hit one of
those frame objects- and with some luck you can take advantage of the
'zombie frame', which is basically just a cached frame with some
assumptions made. Or perhaps you can cause an in-language exception and
hit the right frame object, then you can take advantage of the exception
handling mechanisms in an environment that doesn't have a /SafeSEH option.
There's lots of options, and no one is looking at this type of stuff--
well other than Stephan Esser, and thats (?all?/?mostly?/?whatever?) in
PHP.

What we need to understand is that these scripts can be viewed as an
interface to a C application, that for some reason we expect that the same
people who can't write a mail server, or a web server, or a file server
can suddenly develop an entire environment/language that is bug free, and
this is just utterly absurd. This isn't a testament to the quality of
developers working on Python, its a testament to the complexity of
developing software.

The Python guys have actually been great, They patched the bug the same
day it was reported (shortly after sending off the email here I went and
reported it and hours after that a fix was checked into CVS). They were
polite and their concern appears genuine and thats always a good sign.
Guido contacted me off list wanting to know if there was anything he could
do to help me help him. Python, like any substantial program has it's
bugs, but if you look at the code it's actually pretty simple and very
straight forward-- I understood the callstack in hours, whereas as I work
through the same thing in PERL I begin to agree with a friend who is of
the opinion that it is a code base that wasn't written but instead found
on a crashed UFO (yeah it is that weird...seriously).

If people are interested in this stuff, I'll be speaking about it at
ph-neutral, and pending the responses of other conferences perhaps there
as well. (and thats why the advisory didnt delve into exploitation)

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave