On Tue, 8 Oct 2002, Mikael Olsson wrote: > The above technique was cooked up by me, <mikael.olssonat_private>, > and I would like to thank ICSA labs for taking the time to verify it > against their certified products in spite of me having no hard evidence > to support my theories. I'd personally like to thank Mikael for allowing ICSA Labs to work with the vendors to get the products *fixed* and *tested* prior to this going out.[1] Mikael was incredibly patient, helpful and most of all interested in fixes. The reason that firewalls that were originally vulnerable are fixed and at most require an update, instead of a panic attack is due to the way this was reported and handled. All the full-disclosure ranting in the world doesn't stop the fact that we've got fixed products *before* we've got wild attack code. This does mean that you have to upgrade when your vendor says "time to upgrade," or try to do rush upgrades when CERT advisories come out. If you can't trust your vendor though, you really ought to think about why you're using that vendor's products in a security context. > In closing, this technique can very likely be abused for other protocols > that use ephemeral data channels, although I have personally done no > research in that area. Examples of such protocols (exploitable or not) > include but are not limited to: IRC DCC, SQL*Net, H.323, SIP, Real Audio, > etc ... The Labs folks did communicate the fact that this is more of a class of attack issue than an FTP one with the vendors in the Firewall Product Developers Consortium[2]. In the Labs criteria, FTP is one of the protocols specifically addressed in the testing and certification criteria, so that's been specifically tested and vendors have been upgraded to maintain certification where it's been necessary. FTP is a *darned difficult* protocol to pass well through a firewall. If you've got a firewall in front of your FTP servers, or indeed any server that does dynamic port stuff, that's absolutely not an excuse for not hardening the servers- these sorts of issues will continue to crop up. Paul [1] I'm not speaking for the Labs, TruSecure owns the Labs, etc. [2] Currently certified firewalls, and obviously Clavister's own products don't have this problem. Non-certified consortium members have at least had the chance to be aware of and fix this if their products had it, I'm not aware of who CERT has notified though. ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions probertsat_private which may have no basis whatsoever in fact." probertsonat_private Director of Risk Assessment TruSecure Corporation _______________________________________________ firewall-wizards mailing list firewall-wizardsat_private http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
This archive was generated by hypermail 2b30 : Tue Oct 08 2002 - 12:30:09 PDT