netdev - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1386181774.30495.113.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Wed, 04 Dec 2013 10:29:34 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Fiedler Roman <Roman.Fiedler@....ac.at>,
	Neal Cardwell <ncardwell@...gle.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: Change in IPv4 TCP reset behavior after kernel upgrade

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.



--
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