RE: TCP/IP CRC question

["Clement Dupuis" <cdupuis () cccure org>]

Good day to all,

Lately I had a similar conversation with William Stearns and Joshua Wright
on CRC32 attack on wireless network.  We always hear about potential attack
that are possible but rarely see example of a collision.  Joshua wrote a
brute forcer that allowed him to find a collision as follows for an SQL
update statement:

-----------------------------------------------------------
"UPDATE payroll SET wage = 10.75 WHERE empno = 11"

This is what I'm going to call the "intended data", with a CRC of
0x954f8133.  The adversary-modified data removes the decimal point and
changes the employee number to 18, terminating the SQL and added a comment
to the UPDATE statement:

"UPDATE payroll SET wage = 1075 WHERE empno = 18; --   pN#j,"

Which has a matching CRC as the previous statement.
----------------------------------------------------------------


Although not common, there are ways to get the same CRC32 values or a
collision if someone really wanted to attempt an attack.  It only requires a
bit of programming and patience.

Clement

Clement Dupuis
http://www.professionalsecuritytesters.org  
The Professional Security Testers Warehouse



> -----Original Message-----
> From: Miles Stevenson [mailto:miles () mstevenson org]
> Sent: Friday, October 08, 2004 1:55 PM
> To: security-basics () securityfocus com
> Subject: Re: TCP/IP CRC question
>
> > So, while you are right that it IS redundant to perform  checksums on
> each
> > layer of the stack instead of just doing it on one layer that
> encapsulates
> > the whole packet (such as Ethernet), the protocols had to take this
> > approach to remain independant of the other protocols.
>
> Self correction here. I don't mean to imply that performing a checksum on
> layer 2 (in this case Ethernet) alone would actually work, since the
> original
> Ethernet frame header is removed by a gateway device once it passes
> outside
> the local network.
>
> A few other interesting things to note about checksums:
>
> Ethernet uses a CRC-32 algorithm for the checksum, which is different from
> the
> other layers. CRC checksums are based on long-division, but can actually
> be
> kind of tricky mathematically when you try to implement them. The CRC-32
> algorithm is pretty effective  at avoiding "collisions", which happens
> when
> the data is in fact corrupted, but the checksum happens to match this
> particular corrupttion, as well as the non-corrupted version. Avoiding
> these
> collisions is one of the most important aspects of a good checksum
> algorithm.
>
> The checksum algorithm employed by IP is NOT a CRC checksum, but is
> addition
> based, and comparitively a lot simpler, and a lot weaker than the CRC used
> by
> Ethernet. This is also the same algorithm used by TCP/ICMP/UDP/IGMP
> (although
> TCP uses some of the IP headers to calculate its checksum in addition to
> TCP
> headers). I'm haven't found a good resource analyzing the rate of
> collisions
> with the algorithm employed by IP,  but its not nearly as effective as
> CRC.
> Christopher Abad has written a very interesting paper demonstrating some
> of
> the weaknessess of this algorithm, and how it can be used for a very slick
> covert channel to store data in this checksum field, which would be
> extremely
> difficult if not impossible to detect, because the checksums are still
> valid!
>
> <link to Abad's paper>
> http://downloads.securityfocus.com/library/ipccc.pdf
> </link>
>
> In a previous reponse to this thread, Fernando Gont pointed out:
> <snip>
> > Finally, CRCs and checksums catch different type of errors. Checksums
> catch
> > single bit errors (which usually happen at routers' memories), while CRCs
> > protect data against burst error (continuous bits in the data stream are
> > corrupted).
> </snip>
>
> I haven't found any resources to support this information. Of all the
> resources that I have looked at explaining CRC algorithms and the addition
> algorithm used by IP, "single bit errors" never comes up, and doesn't make
> sense to me mathematically why CRC's only catch "burst errors". This isn't
> meant to be negative toward Mr. Gonts' claims though. If he wouldn't mind
> sharing some more detailed examples to support this, I'd go along with it.
>
> Another interesting thing to note about IP checksums is the need for them
> to
> be recalculated. For example, the IP header has 2 fields which are not
> static, and can change when the packet gets routed from hop to hop: the
> TTL
> field (which gets decremented by each router along its route), and the IP
> Options field (which routers may append information to if requested, such
> as
> record-route, timestamp, etc). When a router along this path changes these
> fields, a new checksum has to be generated.
>
> In the case of the TTL, its as simple as decrementing the checksum value
> (the
> entire algorithm doesn't need to be applied to fix the checksum). But in
> the
> case of IP Options being added, the entire checksum algorithm must be
> applied, using slightly more processing power.
>
> In a brief conversation with Johannes Ullrich of the ISC
> (http://www.incidents.org/), Johannes pointed out that adding IP Options
> to
> the headers could be an effective way of making DoS attacks more deadly,
> because they require a bit more processing per-packet to recalculate the
> IP
> checksums.
>
> Have fun!
>
> --
> Miles Stevenson
> miles () mstevenson org
> PGP FP: 035F 7D40 44A9 28FA 7453 BDF4 329F 889D 767D 2F63