"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
