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

141–150 of 186 posts

Re: SHA-3 Buffer Overflow

#141

Post by londons_explore »

PeterisP wrote: post #69
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).

An obvious issue is that many protocols do two-sided negotiations of crypto algorithms during a handshake - so one of "most applications" which uses SHA-2 hashes by default could be vulnerable to a network connection saying "I don't support SHA-2, let's use SHA-3 pls?" and then exploiting the buffer overflow. In a similar manner, apps that verify signatures/certificates often let the certificate specify which algorit…

> two-sided negotiations of crypto algorithms

This is a common problem, and massively increases attack surface, since if a vulnerability can be found in any algorithm, it can be exploited. Downgrade attacks are a varient of the same.

Let me present an alternative:

Each protocol has one specific encryption algorithm and set of parameters. However, that set isn't fixed, but defined based on the current date and time.

For example, HTTPS could be defined as "SHA1 from 1996 till 2006", "SHA256 from 2005 till 2018", "SHA3 from 2017 till 2032", etc.

The dates can be written 10+ years into the future, so that software deployed today is still usable that many years into the future. As soon as the last date period expires, the software is not usable until it has been upgraded (unless both ends of the communication link choose to fake the date).

There is precedent for software 'expiring' - that happens whenever the root certificate of a trust store reaches an expiry date.

The downside is sometimes an algorithm might be broken before its date comes, and other times an algorithm may still be secure at that date. But that still seems better than our current mess of downgrade attacks.

Re: SHA-3 Buffer Overflow

#142

Post by csande17 »

fulafel wrote: post #105
csande17 wrote: post #87

Earlier quoted context omitted.

The full advisory is linked at https://github.com/XKCP/XKCP/security/advisories/GHSA-6w4m-2... . In order for an application to be vulnerable, it must: 1. Break the file into multiple chunks and pass them to SHA-3 individually. 2. Make one of those chunks larger than 4 GB in size. (This requires using 4 GB of memory.) This is kind of an unlikely thing for an application to do. If you're breaking the file into chunks,…

Nitpick: it requires using 4 GB of address space, not necessarily physical memory - the app might be eg memory mapping the file. (mmap() can be reasonably used for streaming usecases like this provided you use madvise() hints on whether you want the data kept resident after use, probably non unix platforms have similar apis)

Right, mmap() lets you get a big buffer without actually using that much physical memory. Good catch!

I still think it's unlikely for an app to be vulnerable to this but having less than 4 GB of RAM isn't an absolute defense. Having a 32-bit address space probably is, though, if you're running on old or embedded hardware.

Re: SHA-3 Buffer Overflow

#143

Post by pjmlp »

adev_ wrote: post #117
manholio wrote: post #114

Earlier quoted context omitted.

Just another nail in the long overdue C/C++ coffin. If not even these experts can get it right, under the best development conditions, public review and highest stakes, on a relatively small component with the most strict specifications, then no one can.

> Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span and that prevents this kind of out-of-bound access and the party-time that comes with it.

As much as I like C++, std::span would only have helped if the build was built with bounds checking turned on.

ISO on their wisdom has turned the safety defaults around in regards to classical C++ frameworks.

So C++ secure code, either has to make use of Microsoft's gsl::span, or again turn on bounds checking in release builds, you cannot trust everyone to call .at().

Re: SHA-3 Buffer Overflow

#144

Post by adev_ »

manholio wrote: post #140
adev_ wrote: post #134

Earlier quoted context omitted.

> Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behaviour is undefined if idx is out of range" or similar. It is regrettable and under fix but: - You generally do have your own implementation with more advance bound check for safety-critical implementation. - We do have our own where I work right now. - Google has its own in abseil. - span allows the usage for range-for loop which co…

When you are already in a deep hole, it's a good idea to stop digging. How much time did it took you to understand all this? What chances does a beginner has to understand these subtle differences and learn the particular way your codebase uses std::span and not footgun themselves? How much productivity is lost to the sheer terror of such footguns - not actual bugs, but time and effort lost that did not move the prod…

> And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible?

Because the world is a place where billions of lines of code have been written. And these will never be rewritten, but can be modernized.

That the reality, and that's why your web browser right now and most of your OS is still written in unsafe language right now. And will still be for the next 15years at least.

Re: SHA-3 Buffer Overflow

#145

Post by pjmlp »

tialaramex wrote: post #135
adev_ wrote: post #117

Earlier quoted context omitted.

> Just another nail in the long overdue C/C++ coffin C, f**ing C. By the sake of god. Not C++. Stop to put both in the same basket, it just show you do not know what you are talking about. https://github.com/XKCP/XKCP/commit/fdc6fef075f4e81d6b1bc383... Something like that in modern C++ would have been done using std::span and that prevents this kind of out-of-bound access and the party-time that comes with it.

WG21 (the C++ Standards Committee) feels that since idiomatic C++ was unsafe (e.g. array operations don't have bounds checks) it is consistent for new C++ features to also be unsafe by default, even if the whole point of those features in other languages is to provide an idiomatic safe way to do things. So for example in Rust you have a native slice type reflecting a dynamically sized view into a contiguous sequence,…

Tragically, what I would call idiomatic C++ with compiler provided frameworks pre-ISO C++98, made use of bounds checking in their collection classes, and then the C++ Committee went completly to the other way.

Naturally we have now ways to enable them on all major compilers, but many still don't.

This is one point I kind of agree with you.

Re: SHA-3 Buffer Overflow

#146

Post by NicolaiS »

enedil wrote: post #96
SAI_Peregrinus wrote: post #63

Earlier quoted context omitted.

It's a buffer overflow. They can get a vulnerable implementation to execute arbitrary code, so they can get it to return any value they want. The actual SHA-3 algorithm wouldn't return the same value as the vulnerable implementation, of course.

I didn't see anybody mention arbitrary code execution

It's in the post:

    a specially constructed file can result in arbitrary code execution

Re: SHA-3 Buffer Overflow

#147

Post by orangepurple »

adrian_b wrote: post #80
franky47 wrote: post #62

Earlier quoted context omitted.

Note that truncated SHA-2 (SHA-224, SHA-384, SHA-512/224, SHA-512/256) are not susceptible to length-extensions attacks [1]. With the added benefit of better performance of SHA-512 (on 64 bit systems) [2], there's no good reason to use SHA-256 rather than SHA-512/256 for new cryptographic designs. [1] https://en.wikipedia.org/wiki/Length_extension_attack [2] https://crypto.stackexchange.com/questions/26336/sha-512-fa…

There is a good reason to use SHA-256 and not SHA-512. Many modern CPUs, e.g. all AMD Zen, most Intel Atom, Intel Ice Lake and newer, most 64-bit ARM, have hardware implementations of SHA-256, which are much faster than software computing SHA-512. Only some more recent 64-bit ARM CPUs also have hardware for SHA-512 and SHA-3. Whenever the speed matters, SHA-256 is the best choice, unless you choose different hash alg…

Makes me wonder if there is a microcode back door to these hardware hashers such as one which steers the output after the microprocessor is fed carefully crafted input to cause it to run in a vulnerable state.

Re: SHA-3 Buffer Overflow

#148

Post by manholio »

adev_ wrote: post #144
manholio wrote: post #140

Earlier quoted context omitted.

When you are already in a deep hole, it's a good idea to stop digging. How much time did it took you to understand all this? What chances does a beginner has to understand these subtle differences and learn the particular way your codebase uses std::span and not footgun themselves? How much productivity is lost to the sheer terror of such footguns - not actual bugs, but time and effort lost that did not move the prod…

> And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible? Because the world is a place where billions of lines of code have been written. And these will never be rewritten, but can be modernized. That the reality, and that's why your web browser right now and most of your OS is still written in unsafe language right now. And will sti…

Surely "nails in the coffin of C/C++" does not imply an all out effort to rewrite all this existing and working software from scratch.

The beast will die in the same sense Fortran or Cobol are dead: an outdated language that has no noticeable strengths in the modern world, used by a bunch of (difficult to hire) old timers to fix legacy systems.

Re: SHA-3 Buffer Overflow

#149

Post by GTP »

londons_explore wrote: post #141
PeterisP wrote: post #69

Earlier quoted context omitted.

An obvious issue is that many protocols do two-sided negotiations of crypto algorithms during a handshake - so one of "most applications" which uses SHA-2 hashes by default could be vulnerable to a network connection saying "I don't support SHA-2, let's use SHA-3 pls?" and then exploiting the buffer overflow. In a similar manner, apps that verify signatures/certificates often let the certificate specify which algorit…

> two-sided negotiations of crypto algorithms This is a common problem, and massively increases attack surface, since if a vulnerability can be found in any algorithm, it can be exploited. Downgrade attacks are a varient of the same. Let me present an alternative: Each protocol has one specific encryption algorithm and set of parameters. However, that set isn't fixed, but defined based on the current date and time. F…

As you say, it could be that an algorithm gets broken before its "expiry date" or remains secure well past that (look e.g. at AES). There is a similar but better alternative, usually called "opnionated cryptography". A protocol specifies a single cryptographic primitive for each type needed (hash function, block cipher etc) so no negotiation is needed. If one of the primitives gets broken, a new version of the protocol is released that uses a different primitive.

Re: SHA-3 Buffer Overflow

#150

Post by adev_ »

manholio wrote: post #148
adev_ wrote: post #144

Earlier quoted context omitted.

> And most importantly, what is the point of accepting that huge cost instead of writing in a language where unsafe data access is impossible? Because the world is a place where billions of lines of code have been written. And these will never be rewritten, but can be modernized. That the reality, and that's why your web browser right now and most of your OS is still written in unsafe language right now. And will sti…

Surely "nails in the coffin of C/C++" does not imply an all out effort to rewrite all this existing and working software from scratch. The beast will die in the same sense Fortran or Cobol are dead: an outdated language that has no noticeable strengths in the modern world, used by a bunch of (difficult to hire) old timers to fix legacy systems.

> Surely "nails in the coffin of C/C++" does not imply an all out effort to rewrite all this existing and working software from scratch.

Or you use the evolutionary approach: remove the unsafe part from C/C++ bit by bit. And do code migration (Carbon style) when you can do it. This is what some C and C++ committee members try to do and fortunately they are there.

Because that is way more likely to happen in a reasonable time frame (next 15 years) than rewrite Chrome, Linux, OpenSSL, Office and all the other 10 of billions of proprietary code we have around in Rust.

Post reply on HN