Message-ID: <402752BB.7940.1A31C9F9@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Apparently the practice was prevalent

"Paul Schmehl" <pauls@...allas.edu> wrote:

> According to this story, some programmers have been up late "fixing" the
> inability to use @ in their urls. :-)  ...

Yep.

The story is perhaps most interesting for the abject lack of concern 
for standards-conformance and for larger client security issues shown 
by the web application developers interviewed.  Perhaps it is not 
surprising that one of them did not want his employer identified...

> ...  Once company is even proposing
> reversing the change (by sending their users a registry update) so they can
> continue to use the feature.  ...

As I said -- it is interesting how little concern some developers show 
for their clients larger security issues...  I hope Microsoft adds a 
check for the "ungoing" of this fix to MBSA and like products.

> ...  Makes you wonder how long it will be before a
> virus or worm reverses the registry key so it can use that "feature".

Ummmmmm -- to unset the option, the virus would already have to run, so 
I see little additional usefulness to a virus in doing that.  After 
all, "if the bad guy can persuade you to run his program on your 
computer, it's not your computer anymore".  (I guess that some furture 
hole may allow some some very specific and limited access to the 
machine, where this could perhaps be cunningly used -- say a commonly 
deployed ActiveX control that "accidentally" exposed a registry 
modification function to scripting -- hopefully sufficiently unlikely 
that we will not see it...)

> http://news.com.com/2100-7355_3-5153534.html?tag=nefd_top

As there seems to be some interest in this (and some vibrant defense of 
the basic stupidity behind those running services based on non-
standards conforming browser behaviour, here is the response I Emailed 
to Rob Lemos last night:

========================================================================
Hi Rob,

Sadly, your article failed to note that the "fix" MS implemented 
actually put IE more closely in line with the standards that define the 
web's protocols than it was before the fix.  Thus, much of the holier- 
than-thou "they shouldn't mess with us" commentary you cited, for 
example:  

   "Microsoft may have legitimate reasons for addressing the issue, but
   the way they addressed it--an across-the-board kill of an industry
   standard--is troublesome," said James Rosko, a software engineer for
   a data-processing service on the Web. He and other programmers spent
   Tuesday night making changes to the programs that process login
   requests for his company's Web site, which he requested not be
   named. 

shows that the _commentator_ is pathetically mis-informed.

True, this guy (and any others like him) probably designed their now 
broken applications following "advice", perhaps even "encouragement"  
from MS about the use of this form of HTTP URL.  However, MS has a very 
sad history of not doing standards-conformance at all well which any 
professional developer should be aware of.  A consequence of this 
history is that any advice from MS should be checked very carefully not 
against the MS code implementing the features but against the actual 
standards the features supposedly implement.  

In this case any clueful developer would have realized that MS (and 
some other browser developers) was quite wrong in implementing support 
for the generic URI standard's (RFC 2396) _optional_ "userinfo" 
component in HTTP URLs, as this component is clearly defined (RFCs 1945 
& 2616) as _NOT_ part of a valid HTTP URL.  

So, we see it is _incorrect_ of Rosko to claim the feature is a 
"standard" as the standard that defines what an HTTP URL is is very 
clear that this is _NOT_ a part of that standard.  

I have a little sympathy for the Roskoes of the world, but not much.  
They should know that MS is at least as bad at adding things to its 
products that it oughtn't (and then documenting and even encouraging 
them) as it is at mis-documenting "proper" features.  Had MS correctly 
pointed out in its documentation of this feature that it was non- 
standard and therefore its use may cause trouble for users of _other_ 
web browsers I'd have no sympathy for them at all.  

Of course, MS has not helped matters here much -- rather than point out 
that they are fixing an implementation error, where they incorrectly 
support a feature that is not part of the HTTP URL scheme, they simply 
explianed the change in terms of "bad people have been abusing this and 
our customers insisted we prevent this" (makes MS seem rather like the 
victim than the truth that they have, yet again, shot themselves in the 
foot by implementing non-standard -- in fact, anti-standard -- 
behaviour in their products).  

I am also more than slightly concerned at this:

   Aisa wasn't aware of the issue until customers started complaining.

Hmmmmm -- Microsoft relayed this information via a KnowledgeBase 
article perhaps a couple of weeks before it shipped the patch, and that 
KB article was the talk of several mailing lists within a couple of 
days of its posting.  Thus, any modest sized developer that is at all 
security-conscious should have been aware of the forthcoming (and 
fairly clearly explained) change at least ten days before the patch was 
shipped.  And, failing that, what kind of in-house QA is his company 
running if it is not immediately downloading and testing patches and 
updates for by far the single most-used web browser???  

However, if that is not enough security antagonism, it gets worse -- 
much worse:  

   "All of a sudden, you come in one day, and things aren't working
   anymore, because (Microsoft has) determined that a way they are
   doing things is not secure," he said. "There should be an opt-in
   system for that." 

Wow -- unbelievable!

A Windows developer that believes that security improvements in the 
most security-challenged web browser should be "opt-in" rather than 
supplied by default.  This guy must be in line for the security 
industry's "bozo comment of the year" award!  

The abject lack of _customer_ security concerns shown by him this far 
should now not make the following comment in the slightest surprising:  
 
   After looking at the options, Angus Systems will likely have to
   reverse Microsoft's security move by giving people a registry update
   to turn off that part of the patch, Aisa said. 

MS leaving the old behaviour present and able to be turned back on is 
simply begging for exactly this kind of reaction from security-ignorant 
vendors "unhappy" at Microsoft finally instilling standards-conforming 
behaviour into the woefully insecure and historically bug-ridden code 
it has insisted on weaving deep into the OS.  The fact is that far too 
many Windows users are simply too security ignorant to know what to ask 
or what to check.  If one of their suppliers provides them with a 
software update installer or a system configuration change they "must 
make to allow our software to work" most users will expect that this 
vendor knows what they are doing and that, among other thigs, its "fix" 
will not compromise their security.  

The comments of the "web developers" you quote in your article should 
be enough to send any security savvy customers they have looking for 
developers with at least a modicum of security awareness to provide 
those services in future...  

========================================================================



Regards,

Nick FitzGerald

Powered by blists - more mailing lists