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

Post by junon » Tue, Mar 07, 2023, 10:27 AM UTC

loup-vaillant wrote: post #16

drivebycomment wrote: post #12

Earlier quoted context omitted.

Nobody with any experience would laugh at mistakes like this. It's only easy in hindsight. Past 30+ years of collective experience in our industry shows that these classes of bugs are nearly impossible to completely stamp out in any language but especially in memory unsafe ones, even with dramatically better compile time and runtime tools that can spot many of these nowadays. During the early days of the internet and…

This particular mistake is all the more infuriating because it comes from a precaution . Or trying to silence a compiler warning: partialBlock = (unsigned int)(dataByteLen - i); Where both `dataByteLen` and `i` where actually `size_t`. Assuming this is close enough to C, what happens is that we're converting a difference between `size_t` into a mere `unsigned`, and since they're not the same sizes on 64-bit platforms…

Post by [deleted] » Tue, Mar 07, 2023, 10:56 AM UTC

astrange wrote: post #9

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.

Post by Arnavion » Tue, Mar 07, 2023, 11:02 AM UTC

eterevsky wrote: post #20

I wonder if this could be avoided by writing the canonical implementations in Rust or better yet in some system with formal verification. This is such a critical part of the software stack, that we need a more reliable way of validation than just a bunch of people staring at the code written in C.

Post by pas » Tue, Mar 07, 2023, 11:04 AM UTC

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.

Post by jongjong » Tue, Mar 07, 2023, 11:27 AM UTC

drivebycomment wrote: post #12

Donckele wrote: post #10

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, serious…

Nobody with any experience would laugh at mistakes like this. It's only easy in hindsight. Past 30+ years of collective experience in our industry shows that these classes of bugs are nearly impossible to completely stamp out in any language but especially in memory unsafe ones, even with dramatically better compile time and runtime tools that can spot many of these nowadays. During the early days of the internet and…