[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1330295871.1973.11.camel@tiger.regit.org>
Date: Sun, 26 Feb 2012 23:37:51 +0100
From: Eric Leblond <eric@...it.org>
To: oss-security@...ts.openwall.com
Subject: Re: Attack on badly configured Netfilter-based
firewalls
Hello,
On Mon, 2012-02-27 at 01:53 +0400, Solar Designer wrote:
> On Sun, Feb 26, 2012 at 10:05:55PM +0100, Eric Leblond wrote:
> > On Sun, 2012-02-26 at 12:17 -0700, Kurt Seifried wrote:
> > > Are there any helpers that can be abused to open holes in the firewall
> > > externally, or is it only internal clients that can cause problems and
> > > trigger the firewall to improperly allow network traffic in/out.
> >
> > No, attacker has to be on a network directly connected to the firewall.
>
> I guess by "internal clients" Kurt was referring to machines behind the
> firewall (e.g., someone clicking an URL that has a string looking like
> an FTP command embedded in it, thereby triggering the FTP helper to open
> a hole - stuff that was discussed in late 1990s and partially mitigated
> by hardening the helpers at the time), whereas by "attacker on a network
> directly connected to the firewall" Eric means that the attacker may be
> _outside_ the firewall (behind its WAN interface), but on the same
> network segment (e.g., the attacker might have compromised a nearby
> server, such as of another customer at a colocation facility).
This is a correct definition of the condition on the network required
for the attack.
> It is known that a machine will generally receive and process a packet
> routed to one of its NICs by MAC address even if the destination IP
> address is that of another NIC or even loopback (e.g., it is possible to
> access services bound to 127.0.0.1 in this way - but only from directly
> connected machines). Without rp_filter or equivalent, it is possible to
> have these packets' source addresses match the other NIC's network
> segment. My _guess_ (based solely on the info posted in here so far) is
> that the gist of Eric et al.'s new attack is to apply this approach
> against a protocol helper. The novelty is thus in combining these known
> things together to arrive at something that to the best of my knowledge
> has not yet been discussed.
>
> I suppose Eric will tell us if this is the correct guess or not. ;-)
Correct guess :)
BR,
--
Eric Leblond
Blog: http://home.regit.org/
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
