ACTION-32: consideration of non HTTP threats...

I took an action to document an FTP (or really non-HTTP) related
scenario that is maybe not quite irrelevant for WSC.

The scenario is that some web services may be usable via
either HTTP or FTP transports, without the user noticing
(at least until its too late). However, the user's password
may be sent in cleartext when the service is accessed via
FTP. What looks like an example of how this might easily
happen is shown at [1].

(I also found some references to use of FTP as an alternate
vector for password brute force attacks [2], which I found
interesting but is I guess less relevant.)

There are two points to make:

1. Whatever new mechanisms we recommend/derive/whatever, we need
to think about how they work if HTTP is not the substrate protocol.
So, e.g. if we do something based around DNS names, then we mustn't
assume that if some security predicate applies to the web server
(on port 80) at that DNS name, that it also applies to other
services. That's pretty easy for FTP but maybe harder for SIP or
other URI schemes, or for things like BitTorrent. In the end the
user normally has only one browser that does all those things,
so they might have a reasonable expectation of similar security
models or supports in that browser.

2. The more that this group (and industry generally) succeeds in
improving the HTTP security landscape, the more that bad actors
will investigate non-HTTP substrates as delivery mechanisms, e.g.
buffer overruns in FTP proxies are probably less likely to be
detected/patched and are certainly less likely to use a secure
transport, so might thus provide a much better MITM attack point.

Of course, none of this is as important as HTTP (or mail and
then HTTP) use cases. I'm not saying we should devote as much
effort at non-HTTP substrates, but we shouldn't forget them
either IMO. At a minimum, if someone could use another substrate
to demonstrate how to work around whatever improvements we help
create, then this group's work will have a credibility problem.	

Stephen.

PS: A few more FTP-related CVE entries [3,4,5] show that FTP
vulns. aren't all as old, as some (incl. me) might have thought.

[1] http://developer.capeclear.com/?q=customtransports
[2] http://isc.sans.org/diary.php?storyid=1491
[3] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-5947
[4] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-4403
[5] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2004-1165

Received on Monday, 4 December 2006 21:49:32 UTC