In some mail from bugtraq@hackerfactor.com, sie said: > > It seems like a fairly obvious hole, but I could find no mention of > anyone reporting it. [...] > Here's the problem: > Because SRC does not know the route for the packet, ANY system > outside the firewall can reply via ICMP. This means, an ICMP storm > can come inside the firewall. For a NAT router, the storm will be > directed at the specific SRC system. I think you're missing an important ingredient in the mix here and that is said firewall should be using the data returned in the ICMP header to match up the correct outgoing state table entry. This should not allow through arbitrary packets but restrict it to those that match the UDP source ports or ICMP type/code/id#/seq#. If it isn't doing at least that, then yes, there is a bigger problem. So you can't just choose any random destination to do it from but it might easily be possible if you know all that information needed to send packets > An outbound UDP/IP packet can receive a response from either an ICMP, > UDP, or TCP packet. > (Note: I have not tested an inbound TCP packet.) Then why say it can or might be possible ? > From what I can tell, the SMB Barricade treats TCP requests as > special, but everything else is considered to be the same. So, an > outbound UDP connection can have anyone respond with an inbound UDP > or ICMP connection. So what did you actually test and with what product exactly ? I've never heard of the "SMB Barricade" before, but there are probably lots of firewalls, these days, that I've never heard of, but as they always say, "you get what you pay for". Mind you, if you had to part with more than ~$1000 for this, I'd say you were ripped off. > The risks? > - An ICMP storm can enter the firewall at whatever port traceroute uses. > This is mainly a risk for hosts where traceroute can be triggered > remotely. For example: > http://www.usqonline.com.au/sis/public/connection/PingTraceSelected.asp > http://www.traceroute.org/ (Lots of hosts) > You use their tool to kick-off a traceroute to your host. > You receive the packet and determine the port number and IP address. > You kick-off an ICMP storm against that IP/port. > (Like a smurf attack, but with a specific port number.) > As long as the firewall sees incoming traffic, it won't close the > session handle. Thus, you can attack any open traceroute server. And you learn the various bits of information required to successfully match how ? > - If you know that the host is behind a firewall but vulnerable to > an ICMP overflow (e.g., ping-of-death), then you can target and attack. I'm not sure "ping-of-death" is quite so simple as that but maybe I'm forgetting something (like could it be achieved with packets other than ICMP echo?). > Basically, a home firewall that does not manage connections at > layer-4 will be unable to stop this type of attack. But even if it does, there are still "issues", although I'm not sure if you've really considered them. So, in summary, it sounds like you've found a considerably "weak" product which I suppose is a good, general, heads up. There's also a general problem here, that needs attention and that is you really shouldn't allow more ICMP error packets through than you see normal connection packets. ie. one UDP packet out should not allow more than one ICMP error message back in. Having realised this somewhat obvious flaw, I've fixed IPFilter. It's relatively low risk but IMHO it seems like the correct thing to do is limit packet flow to matching packet counts. Darren
