Cut-n-paste responding; first Paul, then Darren: "Paul D. Robertson" wrote: > > > First, just a client side attack scenario as I imagine it: > > > > We plant a link or IMG SRC somewhere, or mail it to them. > > <img src="PORT 1,2,3,4,5,6/bogus.txt"> > > I admit to being a little confused at the first <IMG SRC> tag- do you > expect that in an FTP URI's content somewhere (i.e. ftp://something.html), > an HTTP URI with and FTP port spec, or is that a valid HTML reference? > Snafu. I meant: <img src="ftp://evilserver.int/PORT 1,2,3,4,5,6/bogus.txt"> > Also, don't most HTML clients do PASV only? - Netscape will fall back to active mode. - IE does active by default these days ("FTP folder view" turned on). However, if this is changed, it only understands passive and refuses to fall back to active. - The Squid proxy will fall back to active mode. (Yummy. Attacker gets to connect to proxy port and bounce attacks to intranet servers.) - I can't get opera to fall back to active mode. However, this could be because I suck at FTP response codes. Opera is _very_ picky about the codes it receives, in stark contrast to most other FTP clients. > At the risk of re-ranting over FTP, we *really* need to be moving folks > away from FTP as a protocol. HTTP and SCP both at least get rid of the > whole data/command channel issue. Amen. Of course, then there's H.323 as well as "The Return Of the H.323 from hell": SIP. But that's for another day. Paul Robertson wrote: > [3] Which kind of begs the question should firewalls alert on attempts to > do partial acks if they're able to detect it? Darren Reed wrote: > That aside, my view on this is "funky ACKing" may be within the > bounds of legal TCP operation, but it's not what any "nornmal" > FTP client is going to do so throw those packets away. I've been asking myself this question. It applies to IDSes too. (Indeed, I was pondering IDS evasion techniques when I came up with this.) There _is_ in fact a valid use for partial acknowledgments. - Receiving end checks pool of receive window buffers and comes to the conclusion that there's plenty free. Sends out RWIN=8192 - Sender sees RWIN=8192 and fires off several full-length segments. - Receiver receives segments, but, ACK(tm)! Other sockets snarfed all the buffers! All we can get our hands on is a measly 512 byte one! At this point, the receiver can either just drop all segments, _OR_ grab hold of the 512 first bytes of the first segment, and send out an ACK that only partially acknowledges the first segment. Darren Reed wrote: > But if the attacker has got access to the local filesystem in order > to create [file names with CRLFs in them], then there is little a > firewall of any sort is going to be able to do to stop them. Yes, if an attacker can create file names with CRLFs in them, we're most likely screwed no matter what we're running. However, IMHO, the same _shouldn't_ have to be true for an attacker that simply creates file names (without CRLFs in them) via FTP and issues STAT commands. I'm thinking that f.i. the latest version of ipf stops this, but not the version currently shipping with NetBSD? -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Fri Oct 11 2002 - 05:15:56 PDT