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]
Date:	Wed, 4 Dec 2013 18:56:11 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Fiedler Roman <Roman.Fiedler@....ac.at>
Cc:	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, 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.

Greetings,

  Hannes

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ