On Wed, 16 Feb 2000, Borbely Zoltan wrote: > On Mon, Feb 14, 2000 at 07:32:54PM -0600, monti wrote: > [...snip...] > > > First watch for: > > client -> ftp-server "PASV" > > > > which triggers the firewall to look for this immediately afterwards: > > client <- ftp-server "227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt) > > > > If any other statement is seen from client or server, before the presence > > of the 227 port declaration, the attempt is ignored. > > This solution can't block the exploit. In the following case: > > C -> S "STAT -1" > S -> C "." > S -> C ".." > C -> S "PASV" > S -> C "227 Entering..." > > I know, this is against the RFC, but the SPF firewalls can misinterpret > the whole situation. > > The time frame of the successful attack is very small, but maybe you can > try to close the send window of the server. Maybe it works, but this is just > theory. > Yes good points. As I said, I figured it could probably still be manipulated. My real concern in my reply to checkpoint was that they were putting out a 'patch' that barely fixed the exploit originally posted. And only one incarnation of it at that. I was (as I'm sure most bugtraq readers were) astounded at the weakness of the checkpoint 'fix', and just simply had to point it out. For all I know, they may have planned on a more comprehensive one to follow when they got around to it, but I really just wanted to make sure that this was being brought up. I agree that proper FTP server implementation is extremely important, but the unfortunate and frustrating trend that admins and security people face these days is that 'the firewall' has taken on a role in many minds of being able to cover all the deficiencies of un-patched/un-secured internal/dmz systems. (I'm definitely not advocating this view, I just see it with almost every client I work with to some degree. Bugtraq readers ofcourse know better... right? <cough>). With that in mind, it's a scary (but perhaps encouraging in the long term) thing to see that most people will be cought with their pants down with this sort of vulnerability since the solution is actually the reverse. The end-node has to cover for deficiencies in the firewall. Back to basics (yay!), but how long will it take to get there for some people? .endrant Based on your theoretical attack above (as well as the response from other bugtraq'rs) I get the feeling that maybe an app-proxy --implementing some of the techniques mentioned so far-- might be alot safer for this overall.(?) It seems that the above technique wouldnt be successful if the firewall kept closer track of the order that packets/ftp control messages were sent and arrived. (i.e. actually being an active part in the tcp session) or am I missing something else in this specific instance? (My disclaimer of this still being really hard to truly fix still applies ofcourse). Eric Monti Denmac Systems ericmat_private montiat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:35:54 PDT