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

131–140 of 186 posts

Re: SHA-3 Buffer Overflow

#131

Post by iopq »

consp wrote: post #109
lmm wrote: post #92

Earlier quoted context omitted.

> 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. It absolutely is, and this kind of absolutism is what holds back the adoption of things like rust. In most real world software development, the target defect rate is not zero. The value proposition of something like rust for most businesses isn't that it lets yo…

So your assumption is that most to all defects are language related and not programmer error? I will bet the farm your defect rate will remain the same without any actual validation of what people write. Plenty of errors due to language quirks but lots of times I see missing statements, fixed values which should be variable, input checking failures due to unknown input, incorrect assumptions and lots of non language…

Rust does validation of what people write, it won't let you make a dangling pointer, whereas C will happily accept it if you hide it from the warning heuristics

Re: SHA-3 Buffer Overflow

#132

Post by 6LLvveMx2koXfwn »

hasa wrote: post #130

It may be dumb question, but is there any realistic use case to use this vulnerability to reveal SHA-3 hashed secrets? Or is it just that attacker can crash systems with suitable input?

From the article:

I’ve shown how this vulnerability in XKCP can be used to violate the cryptographic properties of the hash function to create preimages, second preimages, and collisions. Moreover, I’ve also shown how a specially constructed file can result in arbitrary code execution, and the vulnerability can also impact signature verification algorithms such as Ed448 that require the use of SHA-3. The details of these attacks will be made public at a later date.

Re: SHA-3 Buffer Overflow

#133

Post by someweirdperson »

hot_gril wrote: post #124
Cthulhu_ wrote: post #118

Earlier quoted context omitted.

You're optimistic, which is commendable, but unfortunately a naive implementation would probably just read it all. I probably would, because the happy path doesn't deal with 4 GB inputs.

I guess if your test machine always has a lot of contiguous* free memory or you never test it with a large enough file. Otherwise, it's impossible to ignore. One large download, and it wouldn't just be slow, it'd not work at all. * Which is usually much harder than just free mem. I recall macOS always being able to give a huge chunk of memory, I guess by rearranging on the fly, but it's very slow if you ask for a lot…

> And Linux just says no.

Linux might say yes, even if the memory isn't available. See notes of malloc:

"This means that when malloc() returns non-NULL there is no guarantee that the memory really is available." [0]

[0] https://man7.org/linux/man-pages/man3/malloc.3.html

Re: SHA-3 Buffer Overflow

#134

Post by adev_ »

boardwaalk wrote: post #122
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.

Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behavior is undefined if idx is out of range" or similar. For example: https://en.cppreference.com/w/cpp/container/span/operator_at

> 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 combined with subspan() makes possible to avoid pointer arithmetic all together.

Re: SHA-3 Buffer Overflow

#135

Post by tialaramex »

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.

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, and of course it's safe -- five[20] will either refuse to compile if the compiler can see this slice is too short, or it will panic at runtime. In C++ as others have mentioned actually std::span just isn't safe when used ergonomically. five[20] in C++ is Undefined Behaviour. std::optional has a safe interface for a Maybe / Option type, but is presented with a more ergonomic unsafe behaviour and that's what people use.

This is not an old-fashioned thing the C++ Committee grew out of, std::expected is in C++ 23, that's a Result type and it likewise offers an ergonomic unsafe API. The safe APIs were seen as a nice-to-have which could miss the train because who needs safety anyway? Just don't make any mistakes.

Re: SHA-3 Buffer Overflow

#136

Post by YetAnotherNick »

mike_d wrote: post #91
bvrmn wrote: post #30

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

4+ GB inputs are often fed to hashing functions. Verifying the integrity of file downloads before running them for example.

The vulnerability only triggers when you break the file into chunks and make one chunk larger than 4GB.

Re: SHA-3 Buffer Overflow

#137

Post by YetAnotherNick »

Cthulhu_ wrote: post #118
hot_gril wrote: post #107

Earlier quoted context omitted.

But that'll probably run in chunks. Not gonna load 4GB into memory. Edit: Turns out there was another comment like this, and a response was that the file could be mmap'd.

You're optimistic, which is commendable, but unfortunately a naive implementation would probably just read it all. I probably would, because the happy path doesn't deal with 4 GB inputs.

This won't trigger overflow. It will only be triggered if file is broken into chunks.

Re: SHA-3 Buffer Overflow

#138

Post by magicalhippo »

YetAnotherNick wrote: post #136
mike_d wrote: post #91

Earlier quoted context omitted.

4+ GB inputs are often fed to hashing functions. Verifying the integrity of file downloads before running them for example.

The vulnerability only triggers when you break the file into chunks and make one chunk larger than 4GB.

Could easily happen if you compute the combined hash of a set of files, with one chunk per file (mmap'ed fex).

Re: SHA-3 Buffer Overflow

#140

Post by manholio »

adev_ wrote: post #134
boardwaalk wrote: post #122

Earlier quoted context omitted.

Mmmhm. Go look in the docs for std::span and see how long it takes to find "The behavior is undefined if idx is out of range" or similar. For example: https://en.cppreference.com/w/cpp/container/span/operator_at

> 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 product forward?

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

Post reply on HN