From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Westphal Subject: Re: nf_conntrack: Infoleak via CTA_ID and CTA_EXPECT_ID Date: Fri, 30 Jun 2017 21:55:47 +0200 Message-ID: <20170630195547.GN9307@breakpoint.cc> References: <20170630193544.GM9307@breakpoint.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Florian Westphal , "linux-kernel@vger.kernel.org" , Pablo Neira Ayuso , David Miller , netfilter-devel@vger.kernel.org, coreteam@netfilter.org, "netdev@vger.kernel.org" , David Gstir , kaber@trash.net, "keescook@chromium.org" To: Richard Weinberger Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netfilter-devel.vger.kernel.org Richard Weinberger wrote: > Florian, > > Am 30.06.2017 um 21:35 schrieb Florian Westphal: > > Richard Weinberger wrote: > >> Hi! > >> > >> I noticed that nf_conntrack leaks kernel addresses, it uses the memory address > >> as identifier used for generating conntrack and expect ids.. > >> Since these ids are also visible to unprivileged users via network namespaces > >> I suggest reverting these commits: > > > > Why not use a hash of the address? > > Would also work. Or xor it with a random number. > > On the other hand, for user space it would be more useful when the conntrack id > does not repeat that often. That's why I favor the good old counter method. > Currently the conntrack id is reused very fast. > e.g. in one of our applications we use the conntack id via NFQUEUE and watch the > destroy events via conntrack. It happens regularly that a new connection has the > same id than a different connection we saw some moments before, before we receive > the destroy event from the conntrack socket. Perhaps we can place that in a new extension (its not needed in any fastpath ops)?