Re: [Ntp] Last Call: <draft-ietf-ntp-mac-05.txt> / full length-extension attack

[Tim Ruffing <[e-mail]>]

Dear all,

I've recently looked into NTP security and developed a proof-of-concept
exploit for a length-extension attack. It turns out that
length-extension attacks are possible but only under certain exotic
conditions with MD5 and RIPEMD-160. Since we now know that a concrete
attack can be crafted for MD5 and RIPEMD-160, I suggest that draft-
ietf-ntp-mac does not only deprecate MD5 but also RIPEMD-160, which is
not required by RFC 5905 but implemented by ntpd for example. I know
I'm late to the party...

A while ago I reported this to Miroslav Lichvar first, who suggested
that it's okay to post it publicly because the issue looks rather
harmless to both of us. 

Miroslav wrote on the NTP WG list:
> My understanding is that the NTPv4 packet format (with or without
> RFC7822) prevents the length-extension attack as extension fields
> cannot have a length of zero, which would come from the padding
> (always starting with 0x80000000). Even if the length field could be
> zero, there is no EF type 0x8000 assigned yet and it could be avoided
> in future in case people are for some reason still using the old MAC.

The problem here is that this assumes that the length value in the
padding is big-endian, which is not always the case. Notable exceptions
are MD5 and RIPEMD-160, which use little-endian, see
https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks
 for a nice overview.

With little-endian it's actually possible to exploit this. If the
hashed data is for example 117 bytes = 936 bits, then the padding
starts with 0x800000a803 and 0x00a8 (interpreted as big-endian) will be
the length value of an extension field. By adding enough dummy bytes,
the attacker can thus insert a dummy extension field (with type 0x00
and response flag set due to the leading 0x80), which will be ignored
by the recipient. The attacker can then add arbitrary malicious
extension fields after the dummy extension field.

In theory, the same should work when 118 bytes = 944 bits are hashed,
then the padding starts with 0x8000b003, but then the length of the
extension field is already 45059 bytes, which will hopefully be
rejected by most implementations anyway.

Miroslav observed that 119 bytes = 952 bits works, too:
> If the padding started with 0x80b80300, the EF would have a length of
> 768 bytes and could be skipped as an unknown valid EF.

Also, the same attack works for 117 + 64n or 119 + 64n bytes of hashed
data for any integer n due to the blocksize of MD5 and RIPEMD-160. For
packets without extension fields, this happens pretty rarely: It turns
out that we need a MAC key size of 5 + 64n or 7 + 64n bytes. I don't
except these key size to be common. (Some people probably use small
keys/passwords of size 5 or 7 but these can be broken by brute force
search anyway). However, if the original packet intercepted by the
attacker already contains extension fields, then the required key
lengths will be different. Miroslav told me that ntpd probably only
supports keys up to 32 bytes.

I have a working proof-of-concept exploit. It assumes MD5 with a 69
byte key, and chronyd will happily accept the forged packet. An exploit
for RIPEMD-160 should work the same way essentially. I can provide it
if anybody is interested.

Anyway, I think that all of this is not a big issue because I
don't see how the currently defined extension fields could do any harm.
As far as I understand autokey (and I'm sure I don't understand it
fully), the autokey protocol itself relies on signatures because
obviously the goal is to establish a symmetric key -- so if the
peers had already one, they wouldn't need autokey. Also, forging
RFC 7821 extension fields seems pretty harmless to me. Still, MD5 and
RIPEMD-160 should not be used.

Best,
Tim Ruffing