Message-ID: <40CAFF99.6320.740687EF@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: RE:  SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition

"Drew Copley" <dcopley@...e.com> reminded us:

> As a addendum, perhaps, though I wouldn't doubt someone
> might make some nice proof of concept code for this...
> 
> A similiar issue of this kind was found in IE a few
> years ago - remember of course - it is IE's fault that they
> are not properly parsing this, regardless of what they need
> to parse... so this is ultimately a Microsoft bug...
> 
> http://groups.google.com/groups?q=group:bugtraq+dns+wildcard&hl=en&lr=&i
> e=UTF-8&selm=bugtraq/Pine.BSF.4.20.0111142031560.527-100000%40alive.znep
> .com&rnum=1
> 
> Useful extract:
> 
> <quote>
<<snip>>
> Details
> 
>    The details are very trivial. Why am I writing up this big document
>    anyway? Hmm. Loading a URL such as:
> 
>         http://passport.com%20.sub.znep.com/cgi-bin/cookies
> 
>    ...will cause IE to connect to the hostname specified, but send the
>    cookies to the server based on the hostname before the "%20", in this
>    case passport.com. The "%20" is the URL encoded version of a space
>    character. "%20" isn't the only character that works, there are a
>    variety of others that are also misparsed.
<<snip>>
> <end quote>
> 
> Similiar yet quite different in affect, for in one case, you did
> not have full spoofing -- now you have full spoofing, which allows
> you to run code. 

_Also_ quite similar to the much more recent spoofs based on inclusion 
of %00/%01/binary null characters (some of which also affected other 
browsers).  At that time it was reported briefly in a couple of places 
that "some other" non-printing characters had much the same effect on 
IE as the %00 parsing flaw.

This would seem to be yet another flaw in a more general class of 
(HTML) URL parsing bugs.

> I am quite surprised Microsoft did not properly fix this way back
> then. 

Really?

Surely you are just being polite?

This is entirely consistent with a long line of shoddy "fixes" from 
Microsoft (and, to be fair, many other vendors).  Instead of seeing the 
"%20 bug" reported by Slemko above for what it turns out it was -- a 
clear indication something was horribly broken in multiple parts of the 
codebase where (HTML) URL parsing occurs, it is now quite clear that it 
was seen as a "there is a problem if '%20' is present in URLs" problem.

When "fixing" the %00/binary null issue recently, was _that_ seen for 
what it really was -- a clear indication there was something horribly 
broken in multiple parts of the codebase where (HTML) URL parsing 
occurs?

Nope.

Despite all that extra security training the code monkeys in Redmond 
(or perhaps Bangalore?) had as a result of Billy Boy's much publicized 
Security Initiative, the same old blinkers as to locating the source of 
the _reported problem_ were apparently still firmly in place.  Rather 
than opening an exhaustive analysis to uncover the underlying problem 
that could have resulted in them properly fixing the (apparently still 
undiscovered) base cause of the horribly broken (HTML) URL parsing 
code, it seems "fixing the reported %00 problem" was the objective.

Lest anyone think this is an unusual, or possibly unique case with MS 
products, I'll simply point out that we have seen multiple similar 
instances with macro security issues in Word and the other Office 
products where a bug is reported in one or other of the products in the 
suite, fixed and subsequently the same bug is found in yet other Office 
products.  We also saw very similar failures of vulnerability analysis 
in cases such as the Incorrect MIME Type and Incorrect Object Data Type 
vulnerabilities.

The repetitive nature of some of the patterns of vulnerabilities we see 
in its products suggests that the hugely labyrinthine codebase and the 
distributed and always-changing make-up of the teams responsible for 
specific components and products, means that the same functionality is 
implemented over and over by groups who do not talk with each other.  
Given the monstrous size of the whole codebase, its continual, rapid 
growth and the market-grabbing strategy of stuffing more and more of 
what is traditionally considered "application layer" functionality into 
the OS ("the DoJ defence" in the IE/Netscape case and potentially to be 
used in future against media player makers, software firewall makers, 
perhaps AV developers, and no doubt all manner of others) we will see 
many, many more instances of these repeated patterns of vulnerability 
exposure because the scale of the problem is far beyond what the human 
capital at MS can cope with and the problem is computationally 
intractible (ala Turing) so cannot be fixed by throwing more technology 
at it.  As it is incredibly unlikely the whole morass of Windows code 
will be ditched and re-written intelligently from scratch, I am quite 
confident in this prediction.


Regards,

Nick FitzGerald

Powered by blists - more mailing lists