RE: SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition
"Drew Copley" <dcopley@xxxxxxxx> 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