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, 18 Mar 2009 18:47:35 -0700
From:	Oliver Zheng <mailinglists+netdev@...verzheng.com>
To:	John Dykstra <john.dykstra1@...il.com>
Cc:	netdev@...r.kernel.org, Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH net-next-2.6] Re: TCP/IP stack interpretation of
	acceptable packet

On Thu, Mar 19, 2009 at 12:44:53AM +0000, John Dykstra wrote:
> RFC793 says (Section 3.9) that not only should such segments be
> discarded, but that an ACK should be sent to the peer.  I can't see what
> that accomplishes, and it seems to badly interact with fast
> retransmit--under some conditions with crafted packets you can get the
> two stacks ACKing each other forever.  So I left that out of this patch:

I think part of the original intentions for the response ack is to
generate the "ack storm". In certain cases of tcp hijacking where the
attacker is trying to resynchronize a tcp session after injecting a
packet into the stream, an ack storm raises alerts in intrusion
detection systems. Most of the times, built-in measures reset the tcp
session given an unusual large number of acks (I'm not sure how or if
Linux does this).

This was partially the original reason I was looking into this. I
noticed that Windows does not send an ack back if the received ack has
a higher than expected ack number *and* higher than expected sequence
number. For some well crafted tcp hijacking cases, this increases the
attack success rate substantially.

It's beyond my knowledge of other implications such a response ack would
cause.

Cheers,
Oliver
--
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