Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Vulnerability in Implementations of SHA-3, Shake, EdDSA

eprint.iacr.org

Post reply on HN
Print view View original

1–10 of 49 posts

Re: A Vulnerability in Implementations of SHA-3, Shake, EdDSA

#3

Post by cesarb »

eulgro wrote: post #2

I didn't read the whole paper, but how can this even happen? Seems like the buffer overflow would be triggered for any file larger than 4 GiB, which I assume someone has tested in the 8 years since it was released.

> I didn't read the whole paper, but how can this even happen? Seems like the buffer overflow would be triggered for any file larger than 4 GiB

I skimmed the paper, and as far as I understood it:

Most cryptographic hash functions operate in fixed-size blocks (for instance, 32 bytes). Additionally, most cryptographic hash function implementations are designed to be streaming, that is, they do not receive the whole input at once. If you give them a partial input which is not a multiple of their block size, these implementations have to buffer the partial input, so that it can be combined with the next partial input (or flushed, if the next call is to finish the computation and generate the output). The arithmetic overflow which leads to the buffer overflow happens when computing how much it has to buffer, given a partial input and any previous partial input already in its internal buffer.

That is, having a file larger than 4GiB is not enough; it has to also be cut into pieces which are not a multiple of the block size (which is normally a power of two). Most users of a cryptographic hash function will either give it the input in large power-of-two pieces (for instance, 8 KiB or 64 KiB), or give it the input all at once, and thus will not hit the bug.

Re: A Vulnerability in Implementations of SHA-3, Shake, EdDSA

#4

Post by userbinator »

eulgro wrote: post #2

I didn't read the whole paper, but how can this even happen? Seems like the buffer overflow would be triggered for any file larger than 4 GiB, which I assume someone has tested in the 8 years since it was released.

You need to feed it a block slightly less than its blocksize, then another one slightly less than 4GB.

Re: A Vulnerability in Implementations of SHA-3, Shake, EdDSA

#7

Post by caf »

jonstewart wrote: post #5

> partialBlock = (unsigned int)(dataByteLen - i); The paper makes no mention of compiler warnings… but shouldn’t this cast trigger a compiler warning?

No? The effect of that is well-defined, and the cast is a pretty strong signal that the author is deliberately converting the value. Casts to unsigned that deliberately discard the high bits are relatively common.

Re: A Vulnerability in Implementations of SHA-3, Shake, EdDSA

#9

Post by astrange »

jonstewart wrote: post #5

> partialBlock = (unsigned int)(dataByteLen - i); The paper makes no mention of compiler warnings… but shouldn’t this cast trigger a compiler warning?

There is a mode of UBSan that would catch it, but I don't think you could run it on SHA code because that uses unsigned overflow for the hash.

Basically, this is why you shouldn't use unsigned types unless you explicitly want them to overflow.

Re: A Vulnerability in Implementations of SHA-3, Shake, EdDSA

#10

Post by Donckele »

Is this due to stupidity or malice?

I just can’t get my head round the idea that software written and reviewed by experts and submitted to the “National Institute of Standards and Technology” with a budget of 1 billion dollars can fuck up this way.

I’m no mathematician but I would have thought implementing pure number crunching code is not rocket science.

Buffer overflow, overwrite memory, run arbitrary code, seriously? LOL, WTF.

Post reply on HN