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

SHA-3 Buffer Overflow

mouha.be

Post reply on HN
Print view View original

51–60 of 186 posts

Re: SHA-3 Buffer Overflow

#51

Post by tinglymintyfrsh »

duskwuff wrote: post #25
ajsfoux234 wrote: post #3

The vulnerability impacts 'the "official" SHA-3 implementation'. How widely used is it for SHA-3 hashing compared to something like OpenSSL?

SHA-3 is rarely used in general. Most applications still use SHA-2 hashes (such as SHA256).

Rare != bad && rare != unimportant.

The point of NIST standardizing on SHA-3 is to gradually replace SHA-2 due to the rise of computing power and the likelihood it will become as weak as SHA-1 is now in the near future. Unfortunately, like American credit cards vs. European chip & pin, it's going to take forever to adopt.

Re: SHA-3 Buffer Overflow

#52

Post by capableweb »

arisAlexis wrote: post #8

Can someone ELI5 the severity of this over the whole internet? What breaks/what not

Most people limit the amount of input that gets passed to whatever is doing the hashing (SHA-3 in this case) to some amount of bytes that are way less than this issue requires.

Most web servers default to a 50MB limit or something like that, I think, not many things accept by default the size required for this exploit. Most cases would involve services that accept large untrusted files from users.

Re: SHA-3 Buffer Overflow

#53

Post by nullc »

aliqot wrote: post #6

Interesting they both say "Official Sha3" and "by its designers", which as I remember it isn't that accurate. Keccak was chosen and then NIST added what is affectionately known as the 'mystery padding' before certification. What we know as official is not the way the designers submitted the proposal. This isn't an attempt at a scary accusation, but as a pedant, this got me. For those wondering, here is an explanation…

Who actually wrote the faulty code? I had the impression that the padding change was written by the keccak team at the request of NIST.

Re: SHA-3 Buffer Overflow

#54

Post by tialaramex »

a-dub wrote: post #18
metadat wrote: post #5

If you're familiar with SHA-256 and this is your first encounter with SHA-3: The main differences between the older SHA-256 of the SHA-2 family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of FIPS 202, are: * Resistance to length extension attacks. * Performance. The SHA-2 functions—particularly SHA-512, SHA-512/224, and SHA-512/256—generally have higher performance than the SHA-3 functions. Partly this wa…

i thought sha-2 included the message length in the head padding to prevent length extension attacks? just read the link you provided: it's sha-224 and above. i wonder if a similar issue exists in the sha-224+ padding code.

I think you've badly misunderstood what's going on here. SHA-2 includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256. Six functions. Of these SHA-256 and SHA-512 are subject to the length extension attack (and SHA-224 only has 32-bit worth of safety which is clearly inadequate). Since you probably only needed a 256-bit hash, SHA-512/256 is a choice available today which produces a 256-bit hash without the possibility of length extension.

Length extension works because the hash is the entire internal hash function state. This is not true for SHA-224, SHA-384, SHA-512/224 or SHA-512/256 since for these four functions not all of the internal state is exposed.

No, the length is not included at the start of the data to be hashed, this would mean committing to entire input before we hash it, which is a pretty unsatisfactory API, the length is appended (with the padding).

Re: SHA-3 Buffer Overflow

#55

Post by tinglymintyfrsh »

galangalalgol wrote: post #24
lmm wrote: post #21

Earlier quoted context omitted.

> So since no one has mentioned it yet, you could rewrite this stuff in rust as a poor man's substitute. It will catch some of the aame things, but ultimately there is no substitute for test coverage with sanitizers. That's backwards. You'll catch more cases with a Rust-style type system that naturally checks everything, than with sanitisers that can only check the paths that get executed in tests.

Rust isn't perfect. UB is a bug in rust, but it occasionally has bugs. Ideally you'd do rust and asan with good unit tests. And yes, if you only picked one, it should be rust, but don't just pick one. And just because you are using rust is no excuse to skip static analysis like prusti, coverage with gcov, llvm, or tarpaulin, and certainly not unit tests.

There is unlikely ever to be a perfect, but a getting better by constraining behavior that breaks things. Throw all of the compile-time, profiling, checked builds, and binary-level tools at projects for defense-in-depth and checklists, no matter the platform or the application. Fuzzing, valgrind, gperftools, dtrace, {[amt],ub}san, etc. and formal methods like seL4 if you can afford the investment. :>

Re: SHA-3 Buffer Overflow

#56

Post by nequo »

bvrmn wrote: post #30

It looks pretty difficult to exploit. Untrusted 4GB input with non-chunked update.

The purpose of running SHA is to determine whether the input can be trusted though. But it is true that relatively few files circulate at or above that size.

Re: SHA-3 Buffer Overflow

#57

Post by wongarsu »

flatiron wrote: post #11

So if we ported this library to rust sha3 seems peachy? No doubt an interesting port but it now seems inevitable.

Rust code already exclusively uses rust ports of the library. There are a couple competing ones [1][2], but I couldn't even find rust bindings for the official C library. The ecosystem has a bit of a fetish for pure rust dependencies where possible, and this vulnerability seems to vindicate that stance.

I don't think any of those are published as libraries usable by other languages, but doing that would be less than a hundred lines for defining a C interface.

1: https://lib.rs/crates/sha3

2: https://lib.rs/crates/tiny-keccak

Re: SHA-3 Buffer Overflow

#58

Post by tialaramex »

tinglymintyfrsh wrote: post #51
duskwuff wrote: post #25

Earlier quoted context omitted.

SHA-3 is rarely used in general. Most applications still use SHA-2 hashes (such as SHA256).

Rare != bad && rare != unimportant. The point of NIST standardizing on SHA-3 is to gradually replace SHA-2 due to the rise of computing power and the likelihood it will become as weak as SHA-1 is now in the near future. Unfortunately, like American credit cards vs. European chip & pin, it's going to take forever to adopt.

"near future"? I doubt that. Eventually, but likely not in my lifetime.

https://www.imperialviolet.org/2017/05/31/skipsha3.html

Re: SHA-3 Buffer Overflow

#59

Post by oconnor663 »

wongarsu wrote: post #57
flatiron wrote: post #11

So if we ported this library to rust sha3 seems peachy? No doubt an interesting port but it now seems inevitable.

Rust code already exclusively uses rust ports of the library. There are a couple competing ones [1][2], but I couldn't even find rust bindings for the official C library. The ecosystem has a bit of a fetish for pure rust dependencies where possible, and this vulnerability seems to vindicate that stance. I don't think any of those are published as libraries usable by other languages, but doing that would be less than…

I maintain some Rust bindings to the official implementation here: https://crates.io/crates/kangarootwelve_xkcp. I've published an update with today's patch (https://github.com/XKCP/K12/commit/27a84ecb811200990add07a04...). That said, I don't know whether those overflows were exploitable with K12.

Re: SHA-3 Buffer Overflow

#60

Post by tptacek »

nullc wrote: post #53
aliqot wrote: post #6

Interesting they both say "Official Sha3" and "by its designers", which as I remember it isn't that accurate. Keccak was chosen and then NIST added what is affectionately known as the 'mystery padding' before certification. What we know as official is not the way the designers submitted the proposal. This isn't an attempt at a scary accusation, but as a pedant, this got me. For those wondering, here is an explanation…

Who actually wrote the faulty code? I had the impression that the padding change was written by the keccak team at the request of NIST.

The Keccak team wrote XKCP, for whatever that's worth.
Post reply on HN