bugtraq - Re: A new TCP/IP blind data injection technique?

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: <3FD83FA7.1000604@sun.consumer.org.il>
Date: Thu, 11 Dec 2003 11:57:59 +0200
From: Shachar Shemesh <fulldisc@....consumer.org.il>
To: Michal Zalewski <lcamtuf@...ttot.org>
Cc: bugtraq@...urityfocus.com, full-disclosure@...sys.com
Subject: Re: A new TCP/IP blind data injection technique?


Michal Zalewski wrote:

>On Thu, 11 Dec 2003, Shachar Shemesh wrote:
>
>  
>
>>This attack is timing sensitive, route sensitive, and is highly
>>unreliable.
>>    
>>
>
>So is all session injection, but we have seen practical attacks in the
>past. A very popular software to drop Windows 9x users from IRC servers by
>performing a RST packet injection into an existing session worked
>surprisingly well.
>  
>
Presumably, injecting a RST requires you to hit the TCP window with a 
RST packet. You have, at most, 20 bits of entropy on that one. You also 
have to guess the source port, but those rarely have more than 10 bits 
of entropy with NOTHING ELSE being known. Often, something else is know.

>Although the problems you mention make some attacks very difficult, in
>many other cases, this is not an issue. Server-to-server communications is
>often either completely predictable, or can be user-induced (and still
>benefit him in some way when compromised).  In other cases, a low success
>ratio is not a problem when you want to just disrupt communications at
>some point, and do not care about the exact packet for which this happens
>(for all sessions that last for a while).
>
>  
>
Ok, I'll accept that point. Especially as you mention later on that this 
is not necessarily a practical attack.

>>Most TCP/IP connections employ PMTU discovery, and then split the stream
>>at layer 4, rather then perform Layer 3 assembly.
>>    
>>
>It is a matter of OS configuration. Many systems indeed to deploy PMTU
>recently. There is a catch, however: some routers, IP-over-nnn tunnels,
>and some firewalls strip and/or ignore DF flag.
>
That's not the problem I know. I know of routers that ignore the 
"Fragmentation needed but don't fragment set" ICMP. As far as I know the 
suggested workarounds for that one are reducing your own MTU (causing 
TCP SYN to send a lower MSS, and thus still preventing fragmentation).

> This is not as uncommon as
>we would like it to be. I actually have done some research to back this
>claim while writing p0f and encountering some strange discrepancies in
>observed signatures.
>
>  
>
Like I said, I have never heard of that one. Do you have names of 
routers that strip the DF flag?

>I do
>not think this is a threat one should lose sleep over, either, but the
>fact is, it makes session data injection considerably easier than with ISN
>guessing.
>  
>
Can't judge about that one. I will be happy to get answers to the other 
questions, however.

             Shachar

-- 
Shachar Shemesh
Open Source integration & consulting
Home page & resume - http://www.shemesh.biz/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html