I would like to quickly summarise some of the responses I have received to
my original message to BUGTRAQ and Full-Disclosure:
1. Checksum brute-force and attack feasibility
After actually giving it some thought, I do agree the ability to
successfully attack the checksumming algorithm in presence of unknown
ISNs is generally impossible. This means that the fragmentation attack
vector, with perfectly unpredictable ISNs, offers a significant search
space reduction compared to ISN brute-forcing (a transition from
"practically not feasible" to "sometimes feasible"), but still requires
some effort or time to succeed. In some situations, time is not a
problem, in some scenarios, it is.
A note on the exposure: I think there is plenty of server-to-server
communications and some long client sessions that can be either induced
or are easy to detect and attack; but then, DNS cache poisoning by
spoofing UDP responses would also fall in this category (with a
comparable search space and time constrains) - and yet attacks
are very rare, in absence of universal point-and-click tools
and no immediately obvious benefits. To me, this is a targeted attack
that should work in some situations, and is not likely to become a
serious threat to all humanity [*].
The most notable consequence of this observation is that strong ISNs
combined with strong IP IDs on both endpoints are _usually_ sufficient
to prevent the attack, bringing the complexity back to 2^32, which is
probably more than needed for a traditional ISN brute-force - but
see comment B.
Comments:
A. Statistical imperfections of the ISN generation algorithm that were
still beneath the attack feasibility level and thus did not pose an
immediate threat in the traditional ISN brute-force scenario, may
simplify fragmentation attacks on TCP.
In particular, on systems that had just a handful of unpredictable
ISNs bits to start with, just enough to discourage immediate
attacks, may be be an easy prey. Windows comes to mind.
B. Although checksum is *NOT* optional in TCP packets (unlike with UDP), it
seems that there is a notable (albeit unidentified at the moment)
population of systems that do consider it to be optional when set to
zero, or do not verify it at all. I have conducted a quick check
as follows:
- I have acquired a list of 300 most recent unique IPs that
had established a connection to a popular web server.
- I have sent a SYN packet with a correct TCP checksum to all
systems on the list, receiving 170 RST replies.
- I have sent a SYN packet with zero TCP checksum to all systems on
the list, receiving 12 RST replies (7% of the pool).
As such, there seems to be a reason for some concern, even with
random IP IDs, since it only takes one RFC-ignorant party for the
attack against a session to succeed.
2. Path Maximum Transfer Unit Discovery as a solution
I do stand by my observation that PMTU discovery, even if enabled on
some systems by default and not switched off for reliability reasons,
is not a guarantee of no en-route fragmentation.
While developing p0f, I have observed a noticable population of several
percent of origin networks that have DF zeroed on all outbound packets,
even though OS signatures otherwise match PMTUD-enabled OSes. I have
also received plenty of both anectodal and detailed reports of certain
types of routers, firewalls and tunnel software trashing or ignoring
the flag altogether (including a very detailed report of the situation
with Cisco VPN software).
Note that, while many modern end-user systems may indeed come with
PMTU discovery enabled, a number of commercial firewalls, proxies
and so on have DF disabled on all outgoing traffic. A quick glimpse
at p0f database reveals that devices such as Nokia IPSO, CacheFlow
devices, Cisco Content Engine, Dell PowerApp caches and so on
do not deploy PMTUD - and not without a reason, given some notorious
problems with this feature.
--
------------------------- bash$ :(){ :|:&};: --
Michal Zalewski * [http://lcamtuf.coredump.cx]
Did you know that clones never use mirrors?
-----------------------------------------------
http://lcamtuf.coredump.cx/photo/current/
[*] Let's just say I do not have time to poke random software with a large
stick, and as such, I tend to post about things I thought of while
away from keyboard, most of which is more of a hyphotetical threat
than anything else - but neat, nevertheless.
