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.
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'm not ruling out the possibility that someone else suggested this
already and there's a good reason why it isn't sufficient. But
obviously, I can't tell - I can only get the scraps of information that
are considered legitimate for outsiders to see. If you can give an
attack that works without CR/LF or other illegal characters in the ftp
URL, or a case where CR/LF can be legal in an ftp URL, then I'll
reconsider).
Btw, how would mozilla handle
http://www.foo.com/%0AHttp-headers-here%0A%0A ? Are there any situations
where an http header set by a malicious user could cause damage? One
example I can think of is a faked referer header to get into websites
that check the referer, even though such websites are a bad idea in the
first place.
Stuart.
