In article <[EMAIL PROTECTED]>, "Stuart Ballard"
<[EMAIL PROTECTED]> wrote:
> Stuart Ballard wrote:
>>
>> I have to wonder though if there's a better way to solve this bug than
>> just block access to port 25. Isn't it sufficient to refuse to connect
>> to an ftp URL if CR or LF appear in the username or password (because
>> those characters are part of the protocol and no real ftp server could
>> ever accept them)? That way even if someone runs an SMTP server on the
>> ftp port, you *still* can't abuse it.
>
> Oh, and in case anyone hadn't noticed - this is a reason to have open
> security bugs - so that people like me, who aren't security experts but
> may have an insight into the issue, can contribute.
That and there are a whole lot of security experts whose emails don't end
in @netscape.com
> I do understand the tradeoffs involved, but I think that IF you're going
> to deal with these bugs in private, you should make damn sure that you
> solve the bug in the least intrusive way possible. In the example given
> for ftp, the URL isn't even legal (because of the CR/LF in it, which is
> part of the ftp protocol) - why are we even considering blocking
> legitimate URLs when we can prevent the attack by only blocking illegal
> ones?
I think this is the key issue here: we have broken perfectly legitimate
URLs like http://www.host.com:25/. The real solution would have been to
not accept a URL with characters that are considered reserved in the
protocol. Dare I quote from RFC 2396 (which BTW was not referenced in
the bug):
7. Security Considerations
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. Such a guarantee can only be
obtained from the person(s) controlling that namespace and the
resource in question. A specific URI scheme may include additional
semantics, such as name persistence, if those semantics are required
of all naming authorities for that scheme.
It is sometimes possible to construct a URL such that an attempt to
perform a seemingly harmless, idempotent operation, such as the
retrieval of an entity associated with the resource, will in fact
cause a possibly damaging remote operation to occur. The unsafe URL
is typically constructed by specifying a port number other than that
reserved for the network protocol in question. The client
unwittingly contacts a site that is in fact running a different
protocol. The content of the URL contains instructions that, when
interpreted according to this other protocol, cause an unexpected
operation. An example has been the use of a gopher URL to cause an
unintended or impersonating message to be sent via a SMTP server.
Caution should be used when using any URL that specifies a port
number other than the default for the protocol, especially when it is
a number within the reserved space.
Care should be taken when a URL contains escaped delimiters for a
given protocol (for example, CR and LF characters for telnet
protocols) that these are not unescaped before transmission. This
might violate the protocol, but avoids the potential for such
characters to be used to simulate an extra operation or parameter in
that protocol, which might lead to an unexpected and possibly harmful
remote operation to be performed.
It is clearly unwise to use a URL that contains a password which is
intended to be secret. In particular, the use of a password within
the 'userinfo' component of a URL is strongly disrecommended except
in those rare cases where the 'password' parameter is intended to be
public
The founding fathers of our URI scheme have provided us wisdom from the
past: do not unescape characters which have special meaning in the
protocl being used. It says right there in the RFC. Let's follow it,
and back out this blacklisting stuff that is almost gauranteed to break
somebody's legitimate network setup.
