Message-ID: <BFEKIJJHMLFBOPEEFPJHOEBFGKAA.Security@ReliableAnswers.com>
From: Security at ReliableAnswers.com (Shawn K. Hall (RA/Security))
Subject: Apparently the practice was prevalent

Hi Nick,

> 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.


> 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.


> ...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.

rfc2396 describes URI's, rfc1945 and rfc2616 describe the HTTP
**protocol**. They're far from the same thing. HTTP (rfc1945 +
rfc2616) describes the functionality layer, but does NOT address the
naming conventions to be used in addressing systems using HTTP.
rfc2396 ?3.2.2 (http URL) is an abbreviated (and very limited)
description of an HTTP URL 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)."

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. ...

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.


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.


> 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,


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.


> ...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.


> 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.

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.


Back to security. rfc2396 also has this to say (?7):
   A URI does not in itself pose a security threat.
   Users should beware that there is no general
   guarantee that a URL, which at one time located
   a given resource, will continue to do so.  Nor
   is there any guarantee that a URL will not locate
   a different resource at some later point in time,
   due to the lack of any constraint on how a given
   authority apportions its namespace.

A developers reliance on the userinfo portion of a URL within their
application is no less outrageous than reliance on a remote URL
consisting of any other information. No expectation of privacy or
security should be assumed (unless you're an id10t) when providing the
userinfo, but it IS the standard and clients SHOULD provide means to
use URLs including this information, or at the very least ignore this
information or provide a VALUABLE error message instead. Responding
with:

  The page you are looking for might have been
  removed or had its name changed.
  ----------------------------------------------
  Please try the following:
  * Open the userinfo@...mple.com home page, and
    then look for links to the information you
    want.
  * If you typed the page address in the Address
    bar, make sure that it is spelled correctly.

...amounts to absolutely no use at all. If you cannot access
"http://userinfo@...mple.com/" then you can hardly open the homepage
at userinfo@...mple.com, now, can you?


> 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.

rfc1894:
   4.1 Forgery
      DSNs may be forged as easily as ordinary Internet
      electronic mail. User agents and automatic mail
      handling facilities (such as mail distribution
      list exploders) that wish to make automatic use
      of DSNs should take appropriate precautions to
      minimize the potential damage from
      denial-of-service attacks.
      Security threats related to forged DSNs include
      the sending of:
      (a) A falsified delivery notification when the
          message is not delivered to the indicated
          recipient,
      (b) A falsified non-delivery notification when
          the message was in fact delivered to the
          indicated recipient,
      (c) A falsified Final-Recipient address,
      (d) A falsified Remote-MTA identification,
      (e) A falsified relay notification when the
          message is "dead ended".
      (f) Unsolicited DSNs

You'd be a fool to suggest that messages sent by a virus from an
infected computer using whatever email account is available to
propogate the virus was NOT a forgery.


> 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!). 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.

Regards,

Shawn K. Hall
http://ReliableAnswers.com/

'// ========================================================
    One nation under surveillance.

Powered by blists - more mailing lists