netdev - AW: Change in IPv4 TCP reset behavior after kernel upgrade

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] [day] [month] [year] [list]

Message-ID: <2ECE9D9EEF1F524185270138AE2326593BFA6507@S0MSMAIL112.arc.local>
Date:	Thu, 5 Dec 2013 16:41:46 +0000
From:	Fiedler Roman <Roman.Fiedler@....ac.at>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	Neal Cardwell <ncardwell@...gle.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: AW: Change in IPv4 TCP reset behavior after kernel upgrade

> Von: Hannes Frederic Sowa [mailto:hannes@...essinduktion.org]
> 
> On Wed, Dec 04, 2013 at 10:29:34AM -0800, Eric Dumazet wrote:
> > On Wed, 2013-12-04 at 18:56 +0100, Hannes Frederic Sowa wrote:
> > > On Wed, Dec 04, 2013 at 04:13:10PM +0000, Fiedler Roman wrote:
> > > > -static inline void ip_select_ident_more(struct iphdr *iph, struct
> dst_entry *dst, struct sock *sk, int more)
> > > > +static inline void ip_select_ident_more(struct sk_buff *skb, struct
> dst_entry *dst, struct sock *sk, int more)
> > > > {
> > > > - if (iph->frag_off & htons(IP_DF)) {
> > > > + struct iphdr *iph = ip_hdr(skb);
> > > > +
> > > > + if ((iph->frag_off & htons(IP_DF)) && !skb->local_df) {
> > > > if (sk && inet_sk(sk)->inet_daddr) {
> > > > iph->id = htons(inet_sk(sk)->inet_id);
> > > > inet_sk(sk)->inet_id += 1 + more;
> > > >
> > > > ... from 3.10.16 would disable ID setting on some packets, where it was
> done previously. Perhaps this caused problems in and hence behaviour was
> changed by another patch to one of the following kernel versions. Or
> perhaps the additional vserver-patch in my kernel interacted with that
> change and made it first visible after 3.10.17.
> > > >
> > > > At least there has been activity around that part of the TCP-stack near
> the relevant time window, so it is not completely unexpected.
> > > >
> > > > Since it seems, that the patch only affects sending of RSTs, there should
> be no real security impact also: Only difference seems to be, that by sending
> SYNs to closed ports, you now can get some incrementing next ID value (do
> not know, where this number really comes from). With a quick look, I could
> not find out how this ID relates to other ID values of .e.g UDP/TCP activity,
> e.g. for packet spoofing. Only thing that is possible so far (and not very
> valuable from my point of view) is port/firewall-rule probing using SYN on
> closed port, mechanism:
> > >
> > > E.g. icmp uses per-namespace per-cpu sockets where it counts the non-
> DF and
> > > non-local_df fragments and increases that per-socket. TCP-RST use a
> global
> > > per-cpu socket to send RST packets. ip_select_ident does increase
> inet_id for
> > > each sent fragment.
> >
> > Well, it should not, because for this particular socket (assuming you
> > speak of ip_send_unicast_reply()), inet_sk(sk)->inet_daddr is not set.
> 
> Oh yes, actually looking at the code we definitely run into __ip_select_ident
> and generate an inetpeer and use the derived ipid from that.
>
> Roman, I would be very interested why you only experienced that with
> 3.10.21, could you share the specific vserver patch?

I dug out the two previous kernel builds 3.10.17 and 3.10.15. Taking a closer look, 3.10.17 already exposes the changed behaviour. I must have looked over it in the old firewall logs since 3.10.17 was not deployed on all machines, so only weak signal. With the last update, 3.10.21 was widely deployed and from firewall logs after change I first noticed the new RST-packet ID values. I also tested 3.10.15 which still has ID=0 reset packets.

So everything seems to match the hypothesis of single change in 3.10.16 (ip: generate unique IP identificator if local fragmentation is allowed 703133de331a7a7df47f31fb9de51dc6f68a9de8).