From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: Apparently the practice was prevalent

"Shawn K. Hall \(RA/Security\)" <Security@...iableAnswers.com> wrote:

> > 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.
> 
> Read the article which identifies the 'corrective measures' from MS.
> It allows application-level assignments of 'userinfo' rights. These
> developers could provide the ability to use that method within their
> third-party apps with a single registry change.

Yes, _if_ they are embedding the browser control.  If they have an 
"application" that simply uses the straight browser then their "fix" is 
enable the behaviour for the browser and open the client back up to the 
ugliness MS was trying to fix...

> > Ummmmmm -- to unset the option, the virus would already
> > have to run, so I see little additional usefulness to a
> > virus in doing that.
> 
> Actually, you can readily access the registry on win9x in a default
> installation using client-side scripting. This could be done from an
> html email just as readily as a webpage, then either 'encourage' the
> user to click the link or just open up the browser to the page. It's
> not very different from the fraudulent visa 'popup' that simply turned
> off display of the addressbar in the javascript window.open() call
> before redirecting to the 'real' visa site.

You mean this could readily be done because in such a _default_ install 
there were several ActiveX controls that allowed arbitrary registry or 
arbitrary file system access and holes in the Microsoft VM (Microsoft's 
"Java") that allowed any ActiveX control to be run in the My Computer 
security zone from code that was suppoed to be in the Internet zone, 
right?

As users with such unpatched and chronically out-of-date versions of IE 
won't have the option of installing this latest update I don't quite 
see your point.  (And anyway, the "the bad guy got to run his code with 
privileges he shouldn't have" rule atill applies if you are compromised 
through one of those vulnerabilities...)

> > ...non-standards conforming browser behaviour...
> > ...
> > 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.
> 
> You're confusing apples and oranges.

I believe it is, in fact, you that is confused on this -- very, very 
confused.

> rfc2396 describes URI's, rfc1945 and rfc2616 describe the HTTP
> **protocol**. They're far from the same thing.  ...

Agreed, but you see, RFC 2616 defines more than just the HTTP protocol.

> ...  HTTP (rfc1945 +
> rfc2616) describes the functionality layer, but does NOT address the
> naming conventions to be used in addressing systems using HTTP.

I disagree.

For one, it is kind of difficult to intelligently draw your conclusion 
and maintain that this RFC was written by intelligent folk given they 
_introduce_ section 3.2.2 of RFC 2616, "http URLs", thus:

      The "http" scheme is used to locate network resources via the
   HTTP protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

It seems the authors of RFC 2616 thought they _were_ defining the HTTP 
URL syntax and semantics, but perhaps you really do know better...

> rfc2396 ?3.2.2 (http URL) is an abbreviated (and very limited)
> description of an HTTP URL ...

As that section of RFC 2396 is far from "abbreviated" or "very limited" 
and is clearly not a definition of _just_ HTTP URLs, I will assume you 
actually mean the aforementioned section 3.2.2 of _RFC 2616_ -- the one 
whose authors, by your reading, mistakenly believed was a definition of 
"the scheme-specific syntax and semantics for http URLs"...

However, although you got the RFC number wrong, your assessment is 
largely correct.  The section is "abbreviated" (compared to the 
comparable section in the generic URI syntax RFC (2396) and it does 
provide a "very limited description of an HTTP URL".

And there are good reasons for that.

First, all the terms used are used with pecisely their definition from 
the generic URI RFC (2396) so there is no need to go to all the length 
of repeating them.

Second, and the crux of this whole silly debate and a point that you 
seem especially resistant to understanding, is that the authors of the 
HTTP protocol RFC chose to define the syntax of HTTP scheme URLs as a 
limited subset of the generic URI syntax, as they are perfectly 
entitled to do.

Thus, your charge that RFC 2616 is largely irrelevant to understanding 
HTTP URLs is very wrong and dangerously misleading.  An informed 
reading of the relevant RFCs shows, as I have said over and over, that 
"userinfo" fields from the generic URI syntax defined in RFC 2396 are 
explicitly _NOT_ part of HTTP URLs for the reasons I spelled out 
carefully and prettyt much fully in yet another of my responses to the 
RFC comprehension challenged in another message in this (or a closely 
related) thread earlier today.

> ... for the purposes of reference within the
> document, not as the 'last word' on the proper URI naming. The most
> applicable current information is in ?3.2.1 which states:
>    For definitive information on URL syntax and semantics,
>    see "Uniform Resource Identifiers (URI): Generic Syntax
>    and Semantics," RFC 2396 (which replaces RFCs 1738 and
>    RFC 1808)."

Again, I disagree with your reading of RFC 2396.  That specific comment 
is clearly relevant to the issue of deciphering relative and absolute 
URLs _and_ part of that RFC's mechanism for subsuming the full 
technical definitions of terms used in its subsequent sub-sections so 
that it need not redefine those terms itself.  This is obvious if you 
consider the sentence in the context of its whole paragraph (which is 
almost half of the total content of section 3.2.1):

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI [11], depending upon the context of their use. The
   two forms are differentiated by the fact that absolute URIs always
   begin with a scheme name followed by a colon. For definitive
   information on URL syntax and semantics, see "Uniform Resource
   Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42]
   (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification
   adopts the definitions of "URI-reference", "absoluteURI",
   "relativeURI", "port", "host","abs_path", "rel_path", and 
   "authority" from that specification.

> A highly applicable reference is rfc1736 which is the functional
> recommendations for internet resource locators:
>    3. Resource Access and Availability
>       A locator never guarantees access, but establishing
>       access is by far the most important intended
>       application of a resource locator. ...

So?

I don't see what relevance access considerations, per se, have to this 
debate.  My main claim is that MS was especially right to make this fix 
because it establishes standards conforming behaviour (over this 
specific syntax issue) and that is a good thing in and of its own right 
_and_ much more important than that some techno-weenies got their noses 
all bent out of shape largely because they are somewhere between 
security ignorant and security antagonistic...

> rfc2396 clearly states (?3.2.2):
>    URL schemes that involve the direct use of an IP-based
>    protocol to a specified server on the Internet use a
>    common syntax for the server component of the URI's
>    scheme-specific data:
>       <userinfo>@<host>:<port>
>    where <userinfo> may consist of a user name and,
>    optionally, scheme-specific information about how to
>    gain authorization to access the server.
>    ...
>    Some URL schemes use the format "user:password" in the
>    userinfo field. This practice is NOT RECOMMENDED,
>    because the passing of authentication information in
>    clear text (such as URI) has proven to be a security
>    risk in almost every case where it has been used.

Which, just in case you missed it in the many rehashes of this we have 
already done, is _IR-f**king-RELEVANT_ to HTTP URLs _because they are 
defined in RFC 2616 (for HTTP/1.1 and in RFC 1945 for HTTP/1.0) and 
that (they both) says that userinfo components (as defined in RFC 2396) 
are _NOT_ part of HTTP URLs.

In fact, if you go back far enough to, say, RFC 1738, you will find in 
section 3.3:

   The HTTP protocol is specified elsewhere. This specification only
   describes the syntax of HTTP URLs.

   An HTTP URL takes the form:

      http://<host>:<port>/<path>?<searchpart>

   where <host> and <port> are as described in Section 3.1. If :<port>
   is omitted, the port defaults to 80.  No user name or password is
   allowed.  <path> is an HTTP selector, and <searchpart> is a query
   string. The <path> is optional, as is the <searchpart> and its
   preceding "?". If neither <path> nor <searchpart> is present, the
   "/" may also be omitted.

If you follow the rest of the "development" of HTTP URLs through the 
various RFCs you will find that "userinfo" was not "re-instituted" (if, 
in fact, it ever was an RFC-sanctioned component of HTTP URLs...).

> For most, myself included, it is not a matter of 'user' or 'password'
> security - we do not EXPECT this information to be secure (anymore
> than we exect a domain or URL to point to the same actual resource
> forever) - but it *may* be required in certain situations to provide
> user information AT THE URI LEVEL (which is the entire purpose of it
> anyway). If you've ever wanted to provide a brief, URL-appropriate
> addressing method that does not require significant user intervention
> then it's the way to go; it complies with the standards - as opposed
> to simply making something up just for your server.

And my point is not (much) about the relatively low level of "security" 
involved.  True, I'd rather better security be used than lesser, but 
that is not the main position I am debating from here.  My argument is 
that the official syntax has never (or, at least, not for a _very_ long 
time and well before IE 3.0 was released -- RFC 1738 is dated December 
1994 and I doubt IE 3.0 was released before early-to-mid 1996) 
supported "userinfo" components in HTTP URLs.  Your mis-reading of the 
RFCs and selective missing of clear, outright rejections of the syntax 
you seem to support does not convince me even a little bit to change my 
opinion.

> > 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.
> 
> It very much is. The practice of using "user:password" may be insecure
> in the transmission of information, but it is really irrelevant as far
> as the standard goes. It doesn't simply state 'user:password' but
> "user information" which could also include something not anticipated
> to be secure - like a serial number,

I know this, but it is irrelevant.  The practice _is_ non-standard 
conforming.  _How_ the data from the userinfo component is transmitted 
or what the data contains is irrelevant.  The syntax is simply wrong 
and promoting its use wrong.

> The entire purpose of URI's is *to* provide the shortest and most
> convenient means of providing addresses a resource. The difference
> between...
> 
>   Go to http://userinfo@...mple.com/
> 
> ...and...
> 
>   Go to http://example.com/ then do whatever your specific client
> requires (fill in a form or add information to a domain profile) to
> indicate the authorization information is "userinfo" for your account.
> 
> ...is rather significant. Perhaps it could be made more brief within
> the description, but it could also be extended to an entire manual in
> order to provide compliance with every browser in the world. Besides,
> the HTTP Auth instruction does not REQUIRE the login to be in clear
> text, but rather that it can be in any form that both server and
> client agree on - which could be as secure as necessary.
> 
> Further, just because something appears in the URL does not mean that
> is how it must be sent to the server. For example, if the fragment
> identifiers were all returned to the server instead of processed on
> the client every request could potentially make dozens of redundant
> trips and servers would have to process and filter out fragment
> identifiers from otherwise valuable path/query data.

Again (still...) this is irrelevant.  Those issues are not really my 
concern.  What concerns me is that this practice has become somewhat 
common because folk who should be savvy enough to know better took 
Microsoft's advice and/or simply cannot read and fully understand the 
RFCs.  I mean, what part of "No user name or password is allowed" from 
RFC 1738 did you not understand?  Presumably the same part the MS 
programmers did not understand, or at least wilfully ignored...

> > ...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!
> 
> No. Like everything else, it should be clearly identified when the
> installation occurs. Neither changing default address processing
> behavior or leaving a potential security hole open are good places to
> be. What should have happened was a prompt during installation (and
> optionally a commandline switch) to either enable or disable this
> 'feature' during the patch installation.

I guess that makes sense if you labour under the misunderstanding that 
the behaviour was "correct" or "standard" or some such nonsense.  
Hopefully you have now been disabused of that...

> > If [a customers] 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.
> 
> Interesting - you just used the same argument in SUPPORT of MS
> releasing a "patch" which compromises existing client behavior.

Indeed, but the "existing client behaviour" was incorrect and should 
not have been there from the outset.  I said when the patch was first 
released that MS _NOT_ coming forward and being brutally honest and 
saying "Look, we screwed up way back with IE 3.0 and introducing then 
promoting this functionality.  It is just wrong and we're really sorry 
of you were gullible enough to believe us all this time, but we really 
must remove this mis-behaviour to make IE standards-conforming _and_ 
more secure".  Instead it tried to play the "we've been picked on by 
these mean phishing scams and had to remove an otherwise useful 
feature".  At least if it had taken the first approach MS would have 
been standing on the higher moral ground (perhaps that realization 
frightened them?  It would certainly be an unusual place for MS to find 
itself...) but instead it went the "let's hope the sympathy vote 
outweighs the indignant protestations" route...

> It's a moot point anyway, since the 'fix' the supplier provides need
> only affect his application, and not the entire system. Well, unless
> 'his application' is internet explorer or windows explorer.

That was what I had in mind -- some weakly protected web app that 
simply uses the browser as its front-end rather than a client-run 
executable that hosts the IE ActiveX controls, etc.

> Back to security. rfc2396 also has this to say (?7):
<<snip>>

Nope, rather not as that aspect is NOT what concerned me.

> > Sending complete copies of virus-carrying Email
> > messages to sender addresses the virus scanning
> > Email gateways know are forged is a DE FACTO
> > standard.  As "hggdh" says, what defines a de
> > facto standard is prevalence of use and we all
> > know that virtually all Email gateway virus
> > scanners do this. Nobody can argue that
> > "bouncing" such viral Email messages to known
> > non-senders is not prevalent...
> 
> DE FACTO or not, bouncing virus messages and any other messages that
> can be reasonably assumed to be forgeries is against the RFC's, too.
<<big snip>>

But so is using "userinfo" components in HTTP URLs.

And note, I was parodying something to show how stupid it was -- I was 
not actually arguing that bouncing viruses "back" to known-to-be-forged 
addresses was desirable or to be encouraged.  Debating this with me is 
pointless as you missed the humour aspect to it...

> > Second, you are suggesting that IE should hide the
> > fact that there is some kind of authentication
> > involved.
> 
> No, I believe what he said was "Wouldn't it make sense to accept
> user@...s, but NOT DISPLAY IT on the address bar?" - which is to NOT
> DISPLAY IT IN THE ADDRESS BAR. Like the cute little 'lock' in the
> status bar, something equally as functional could have been done. The
> thing about the display of the userinfo values is that this
> information has consistently been an issue with IE. Previously it used
> to display the password in the address bar throughout the duration of
> the visit (now duh, that's a security risk!).  ...

No, now MS has realized that it is an obfuscation risk that can further 
enhance other security risks.  And I still reckon they should have 
justified the behaviour change on the standards-compliance grounds...

> ...  At one time it also
> displayed in in the title bar when a <title> tag was not present.
> Again - just a rather obvious thing to exclude from the 'default'
> diplay methods - whether they accurately follow the URI scheme or not.

You clearly missed the significance of my comment.  There are folk now 
who are so stupid as to believe that "because the user can't see it it 
is 'safe'".  This suggestion, were it implemented, would simply add yet 
another way such morons could "deliberately yet unwittingly" open up 
their even less clueful customers to abuse.


Regards,

Nick FitzGerald

Powered by blists - more mailing lists