Re: Two MSIE 6.0/7.0 NULL pointer crashes

[Christian Sciberras <uuf6429 () gmail com>]

"Sometimes the vulnerability itself is a functional requirement (or
considered to be one of them). Has anyone mentioned ActiveX?"
Or NPAPI for the matter. Really, other then the
automated-after-user-accept-installation they're both the same.

On Sun, Feb 28, 2010 at 9:22 PM, Pavel Kankovsky <
peak () argo troja mff cuni cz> wrote:

> On Sun, 24 Jan 2010, Dan Kaminsky wrote:
>
> It took me more than one month to write this response? Ouch!
>
> > >  When you discover the program is designed too badly to be
> > > maintained, the best strategy is to rewrite it.
> > No question.  And how long do you think that takes?
>
> It depends. Probably in the order of several years for a big application.
>
> On the other hand, existing code is not always so bad one has to throw it
> out all and rewrite everything from the scratch in one giant step.
>
> > Remember when Netscape decided to throw away the Navigator 4.5
> > codebase, in favor of Mozilla/Seamonkey?  Remember how they had to do
> > that *again* with Mozilla/Gecko?
>
> Mozilla (even the old Mozilla Application Suite known as Seamonkey today)
> has always been based on Gecko (aka "new layout", "NGLayout").
>
> The development of Gecko started in 1997 as an internal Netscape project.
> Old Netscape Communicator source (most of it) was released in March 1998.
> The decision not to use it was made in October 1998. Gecko source was
> released in December 1998. Mozilla 0.6 was released in December 2000,
> 0.9 in May 2001 and 1.0 in June 2002. This makes approximately 5 years.
>
> Firefox started as a "mozilla/browser" branch approximately in April 2002
> (the idea is probably dating back to mid 2001). The first public version
> known as Phoenix 0.1 was released in September 2002, 0.9 was released in
> June 2004, 1.0 in November 2004. 2.5 years.
>
> To put thing into a broader perspective: MSIE 5.0 was released in March
> 1999, 6.0 in August 2001, 7.0 in October 2006, and 8.0 in March 2009.
> This makes 2.5 years from 5.0 to 6.0, 5 years to 7.0 and 2.5 years to 8.0.
> The development of Google Chrome is reported to have started in spring
> 2006 and 1.0 was released in December 2008. 2.5 years again (but they
> reused WebKit and other 3rd party components).
>
> > "Hyperturing computing power" Not really sure what that means,
>
> The ability to solve problems of Turing degree [1] greater than zero.
> "Superturing" is probably a more common term although various terms
> starting with "hyper-"  are used as well [2].
>
> (Alternatively, it can relate to a certain kind of AIs in Orion's Arm
> universe [3] but that meaning is not relevant here. <g>)
>
> For the most part it is a purely theoretical notion but there is at least
> one kind of oracle that is more or less physically feasible: a hardware
> random number generator--such an oracle might look pointless but quite a
> lot of cryptography relies on the ability to generate numbers that
> cannot be guessed by an adversary.
>
> Anyway, real computer are not true Turing machines and they are not turing
> complete. The point of my comment, translated into a more realistic
> setting, is as follows: one must assume the attacker can wield much more
> computing power than the defender.
>
> [1] <http://en.wikipedia.org/wiki/Turing_degree>
> [2] <http://en.wikipedia.org/wiki/Hypercomputation>
> [3] <http://www.orionsarm.com/eg-topic/45c54923c3496>
>
> > > But I do not think this case is much different from the previous one:
> > > most, if not all, of those bugs are elementary integrity violations
> > > (not prevented because the boundary between trusted and untrusted data
> > > is not clear enough) and race conditions (multithreading with locks is
> > > an idea on the same level as strcpy).
> > Nah, it's actually a lot worse. You have to start thinking in terms of
> > state explosion -- having turing complete access to even some of the
> > state of a remote system creates all sorts of new states that, even if
> > *reachable* otherwise, would never be *predictably reachable*.
>
> I dare to say it can make the analysis more complicated if the
> ill-defined difficulty of exploitation is taken into consideration.
>
> In many cases the ability to execute a predefined sequence of operations
> is everything you need to reach an arbitrary state of the system (from a
> known initial state). You do not need anything as strong as a Turing
> machine, even a finite state machine is too powerful, a single finite
> sequence of operations (or perhaps a finite set of them) is sufficient.
>
> > I mean, use-after-free becomes ludicrously easier when you can grab a
> > handle and cause a free.
>
> I admit use-after-free does not fit well into the two categories I
> mentioned. But it is still a straightforward violation of a simple
> property (do not deallocate memory as long as any references to it exist)
> and it is quite easy to avoid it (e.g. use a garbage collector).
>
> > Sure.  But we're not talking about what should be done before you
> > write.  We're talking about what happens when you screw up.
>
> I do not think it is reasonable to separate these two questions.
> After all people are supposed to learn from their mistakes and avoid them
> in the future.
>
> > > (An interesting finding regarding the renegotiation issue: [...]
> > Eh.  This was a subtle one, [...]
>
> I do not want to downplay the ingenuity of Marsh Ray and Steve Dispensa
> (and Martin Rex) but...
>
> Any attempt to formalize integrity properties SSL/TLS is supposed to
> guarantee would inevitably lead to something along the lines of "all data
> sent/received by a server within the context of a certain session must
> have been received/sent by the same client". And I find it rather
> unplausible the problem with renegotiations would avoid detection if
> those properties were checked thoroughly.
>
> > > > c) The system needs to work entirely the same after.
> > > Not entirely. You want to get rid of the vulnerability.
> > I wouldn't consider being vulnerable "working" :)  But point taken.
> > The system needs to meet its functional requirements entirely the same
> > after.
>
> Sometimes the vulnerability itself is a functional requirement (or
> considered to be one of them). Has anyone mentioned ActiveX?
>
> --
> Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
> "For death is come up into our MS Windows(tm)..." \ 21st century edition /
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/