full-disclosure - Microsoft Faces Angry IE Users' Questions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <40F2C2D8.13353.B0AF8E3@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Microsoft Faces Angry IE Users' Questions

"Eric Paynter" <eric@...ticbears.com> to me:

> > You need look no further back than the
> > kerfuffle a couple of months ago over the removal of IE's patently
> > incorrect support for "user:pwd@" userid data in http URIs for an
> > example, but there are many other, earlier examples.
> 
> I'm a little confused by what you mean here.  ...

Then read the RFCs more carefully...

> ...  The "user:pwd@" prefix is a
> part of the URI standard documented in the RFC.  ...

Yes, it is part of the _general_ URI scheme.

However, if that is _ALL_ you recall from that RFC you are out of your 
depth to be discussing this.  More importantly than defining the 
general URI form (with _or without_ the "userid" feature), the URI RFC 
_explicitly defers_ to protocol-specific URI definitions in other, 
unspecified RFCs _for any specific protocol URI_.  Thus, before you can 
say anything meaningful about HTTP URIs you have to find if the HTTP 
protocol URI was explicitly defined in any other RFC(s).  Before 
Christmas 2003 I was of the same opinion you are, because I had not 
found an "HTTP URI" RFC, but as someone pointed out in these lists late 
last year, the HTML RFCs define the HTTP URI (rather than having just 
that in an RFC of its own) and the most recent HTML RFC deliberately 
defines HTTP URIs sans the general URI RFC's "userid" concept.

So, RFC-compliant browsers do _NOT_ support the general URI's userid 
feature in HTTP URIs.

> ...  As far as I can tell, the
> patently incorrect part is that they removed it and thus made the browser
> (even more) lacking in standards support.  ...

Please read all the relevant RFCs and correct your misunderstanding 
then...

> ...  It's a simple example of how MS
> solves problems:
> 
> 1. Fix the feature that is vulnerable
> 2. Disable the feature that is vulnerable
> 
> Lately, they just disable the feature. At this rate, pretty soon, Windows
> won't do much.

Well, in the case of removing IE's support of the general URI RFC's 
"userid" feature, 2. clearly collapses into 1. as the fault was that IE 
supported an explicitly defined non-feature.  MS did precisely the 
right thing and anyone that belly-ached that some useful feature they 
had depended on had been removed should simply be biffed with the 
cluebat, as they clearly were using non-conformant web pages.

As for the more general claim that MS is removing functions from 
Windows...  First, there are an awful lot (or is that "lot of awful"?) 
features they'd have to remove before Windows started to be non-
functional.  Second, a lot of Windows' security problems are directly 
traced to the fact that it tries to be all things to all folk -- such 
wide open generality is widely known in CS circles to come at the price 
of performance due to the necessary complexity such an approach 
entails.  In general, complexity is natural enemy of security because 
"the devil is in the details" and when you have unbounded, featuritis-
driven complexity you get unmanageable layers of complexity hiding ever 
more such layers.  Stripping some of those layers out can only be the 
beginning of something good for the security of Windows' users...

Regards,

Nick FitzGerald