netdev - Re: TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised

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: <541831C3.9020705@oktetlabs.ru>
Date:	Tue, 16 Sep 2014 16:49:07 +0400
From:	Andrey Dmitrov <andrey.dmitrov@...etlabs.ru>
To:	Yuchung Cheng <ycheng@...gle.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
CC:	netdev <netdev@...r.kernel.org>,
	"Alexandra N. Kossovsky" <Alexandra.Kossovsky@...etlabs.ru>,
	Konstantin Ushakov <kostik@...etlabs.ru>
Subject: Re: TCP connection will hang in FIN_WAIT1 after closing if zero window
 is advertised

On 16/09/14 03:37, Yuchung Cheng wrote:
> I think the vulnerability comes from the peer/attacker actually
> responds to the probes to evade the orphan counts or memory checks in
> tcp_probe_timer(). This is a gray area of being legit but suspiciously
> mis-behaving?
> maybe have socket option TCP_USER_TIMEOUT for apps to cover conditions
> like these.
Yuchung,
I've tried to use socket option TCP_USER_TIMEOUT, but unfortunately it 
does not help here. I think it is because all packets get their 
acknowledges.

To everybody,
As I understand there is a sensitive difference in the connection 
behavior when the zero window is advertised. In this case there is no 
warranty that after socket closing the connection will be actually 
closed in a finite time. And probably this cannot be regulated at the 
moment. On the other hand if the zero window was not advertised, user 
can be sure that the connection is closed in a finite time despite on 
any peer actions. Moreover user can configure this time with the 
corresponding timeouts. I.e. a user has a lot of options to configure 
different timeouts, but in fact despite on his actions he has no 
guarantee that the connection will be closed at all.

Thanks,
Andrey

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