netdev - Re: [tproxy,regression] tproxy broken in 2.6.32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091128190500.GB12264@sch.bme.hu>
Date:	Sat, 28 Nov 2009 20:05:01 +0100
From:	KOVACS Krisztian <hidden@....bme.hu>
To:	jamal <hadi@...erus.ca>
Cc:	Patrick McHardy <kaber@...sh.net>,
	KOVACS Krisztian <hidden@....bme.hu>,
	KOVACS Krisztian <hidden@...abit.hu>,
	Andreas Schultz <aschultz@...p10.net>, tproxy@...ts.balabit.hu,
	netdev@...r.kernel.org
Subject: Re: [tproxy,regression] tproxy broken in 2.6.32

Hi,

On szo, nov 28, 2009 at 12:36:14 -0500, jamal wrote:
> On Sat, 2009-11-28 at 18:07 +0100, Patrick McHardy wrote:
> 
> > Right, its source validation. But the setup is valid, its asking for
> > specifically marked packets to be delivered locally for transparent
> > proxying. There's no requirement that rules using marks must resolve
> > to RTN_UNICAST.
> 
> True, but that requirement is needed for source validation;->
> i.e it is source address validation imposing the requirement
> that we must have a RTN_UNICAST route. The tproxy iproute setup entered
> a route that was not RTN_UNICAST. I think that the packet deserves to be
> beaten with a club then dropped hard into an abyss (Feel free to come up
> with  something more medievial to do to it Patrick;-> )
> 
> It doesnt make sense to have a source address that is not unicast
> belonging to a host or pretending to belong to a host.

The source address *is* unicast. The problem is that the routing setup is
asymmetrical, as Patrick has already mentioned: we're using a mark to
force certain packets (those that have matching sockets on the host) being
delivered locally.

In the other direction, reply packets won't be marked by the iptables
rules and thus will be routed on egress just fine. Your modification has
the assumption that routing is symmetrical, and that reply packets will
have the same mark. That assumption is not necessarily right, and I think
it's not entirely unreasonable to think that not only tproxy setups will
be broken by the change.

> So i didnt introduce that logic thats causing this pain.

Well, it depends whether or not you consider the initial setup valid.

> If it worked before it was hack or fluke imo ;-> If we think that
> source address validation needs to check for something else
> additionally, i think thats a separate topic (but doesnt
> seem worth a change)

My only concern is that this definitely breaks current setups, and while
we do have a workaround we don't have a way to let all users know what
needs to be done...

-- 
KOVACS Krisztian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html