Re: The inability to deliver a secure implementation is an architectural flaw.

["Halvar Flake" <halvar () gmx de>]

Hey all,

First of all congrats to Mark & Ben.

I do find the quote from the "seven analysts over ten weeks" amusing.
Clearly, nobody
would ever invest more than that much work in obtaining classified
information.

The real beauty in NaCl is that it is certain to defeat DEP for the
attacker. Not that DEP is much
of an obstacle in browsers these days, but still. It'll also almost
certainly allow ASLR bypass.

Everyone who has even been to one of my classes has been tortured with
the analogy that
"writing an exploit is like trying to build a chair out of a number of
random parts from the IKEA
warehouse: Nothing ever fits, but the more pieces you have, the better
your odds of success are".

The power to first execute Javascript to perform
allocations/dealloctions, coupled with the ability
to load arbitrary code into the address space that is only verified
under alignment assumptions violated
as soon as you can perform a control hijack, does look like a jar of
superglue to me. And when you have
a sufficiently large jar of superglue, you can essentially build a chair
out of wood shavings.

Cheers,
Halvar

Dave Aitel wrote:
> Congrats to Mark Dowd and Ben Hawkes on winning the Google Native Client
> contest. But the google blog gives you pause:
> http://googlecode.blogspot.com/2009/07/native-client-security-contest-results.html
>
> So in the CLOUDBURST talk we quote the a DOD private unclassified journal as
> a lesson's learned:
>
> “The Next Wave”
> Vol 17 No 3 - 2008
>
> "Using seven analysts over a ten week period and with some limited input
> from VMware developers, we explored the ability of the core NetTop
> technologies – VMware running on a Linux host – to maintain isolation [...].
> The results of this first study were encouraging – no apparent show-stopping
> flaws were identified.”
>
> NetTop is a virtualization based system that establishes a "virtual air gap"
> between two VM's running at different classification level. When systems
> like that have failures, the result is strategic. It's not patchable. The
> article is interesting and talks about how while the technical review staff
> were against the idea, they got pushed over and the system was deployed
> "successfully"!
>
> I thought it was interesting the same verbage came from the Google Blog
> today re: Native Client.
>
> """
> This contest helped us discover implementation errors in Native Client and
> some areas of our codebase we need to spend more time reviewing. More
> importantly, that no major architectural flaws were found provides evidence
> that Native Client can be made safe enough for widespread use.
> """
>
> At some point someone senior at any project like this needs to quantify the
> level of testing that is required to build a secure product. Contests are
> interesting, but they're not providing evidence of architectural safety. All
> we learned here was that with some minor level of effort, lots of bugs can
> be found. That's not a good sign. Although it's impossible to prove "there's
> no bugs", it IS possible to decide not to do stuff you can't reasonably do.
> That's how you avoid getting on the "advisory treadmill".
>
> -dave
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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