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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Breaking the checksum (a new TCP/IP blind data injection technique)

First, let me apologize to all readers of the list who have no particular
interest in the subject; I should not have generated so many posts, and I
solemnly swear this is the last one. I posted my first thoughts on the
subject perhaps a bit prematurely, and agreed with Nick Cleaton's response
to my question on the (in)ability to bypass IP checksums while preparing
the summary of the feedback I have received. This assumption, in turn,
downgraded the feasibility of the attack significantly, requiring an
attacker to brute-force a 16-bit checksum in order to succeed.

Ivan Arce, however, gave me a reason to rethink this assumption, and I am
glad to conclude that the ability to bypass checksumming indeed
exists,just as I suspected initially. This means the attack is quite
feasible, and can be accomplished in one shot, and provides a very
attractive alternative to a traditional TCP/IP injection attack,
undermining the effectiveness of ISN-based protection, and rendering
random IP IDs not a sufficient protection against this attack.

The attack has but one prerequisite - a section (and only a section!) of a
TCP/IP packet the attacker wants to replace is known to the attacker in
advance. This holds true for cases such as FTP or WWW file downloads and
other situations that are most likely to cause fragmentation to start
with. It is possible to tweak the packet so that the checksum remains
valid, even though portions of the packet such as the sequence number (or
the checksum, for that matter) are not known in advance.

The checksum algorithm used in TCP/IP is fairly trivial (a form of an
16-bit sum), and position- and ordering- insensitive, we can perform a
simple trick:

  - Pick a known fragment of the packet (at 16-bit boundaries) and
    compute it checksum,

  - Construct a malicious replacement for this block, of arbitrary
    contents, closing with two bytes used to compensate the checksum
    so that it comes out the same as for the original block - this
    is trivial with this type of an algorithm,

  - Replace the old block with the malicious one.

The checksum of an entire packet would remain the same, even though we did
not know what it was in the first place, and did not know the entire
packet (port numbers and sequence / acknowledgment numbers are, once
again, not known to the attacker).

So, in short:

  - The attack DOES NOT require any brute-force and can be
    conducted using a single packet.

  - The attack requires the traffic exchanged between two endpoints
    to be fragmented at some point; this is most likely to happen
    on file downloads, etc.

  - The attack may be used to bypass ISN-based integrity protection of
    TCP streams (such as the solution suggested in RFC1948).

  - The attack has to be targeted against a specific connection
    the attacker either induced or knew about. The attack is also
    time-sensitive.

  - The impact is insertion of malicious data into an existing
    stream.

  - A knowledge of some of the plaintext is necessary.

  - Random IP IDs enabled on both endpoints make the attack more
    difficult, but still relatively feasible. Sequential IP IDs
    make the attack trivial.

  - Path MTU Discovery enabled on both endpoints may prevent the
    attack, but only as long as there are no DF-ignoring
    devices en route (and no proxies that do not use PMTUD).

-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2003-12-14 15:01 --

   http://lcamtuf.coredump.cx/photo/current/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ