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

111–120 of 186 posts

Re: SHA-3 Buffer Overflow

#111

Post by green_on_black »

tialaramex wrote: post #44
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.

There are various crates with pure Rust implementations of SHA3 or of the Keccak functions, I would expect that they just don't have the bug, although it's possible they instead panic under the circumstances invoked in this exploit. (safe) Rust writes actual bounds checks, so if you accidentally overflow a buffer in some case you never tested that compiles, it would just panic if the case you got wrong occurs in real…

It seems that some memory safety bug in C/C++ makes HN frontpage every other day.

Re: SHA-3 Buffer Overflow

#113

Post by lmm »

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…

> So your assumption is that most to all defects are language related

What does that even mean?

> I will bet the farm your defect rate will remain the same without any actual validation of what people write.

In what sense is a typechecker (or the rust borrow checker) not "actual validation", but a static analyser is?

> 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 gelated bugs

Most of those sound like type errors to me. Errors where the program isn't doing what the programmer thought it should can generally be avoided by using more precise types. (The more insidious case is where the program is doing exactly what the programmer thought it should, but they've misunderstood the specification or not thought through the implications - but no kind of testing can catch that kind of bug).

Re: SHA-3 Buffer Overflow

#114

Post by manholio »

Donckele wrote: post #104

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.

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.

Re: SHA-3 Buffer Overflow

#116

Post by dcow »

baby wrote: post #75
duskwuff wrote: post #72

Earlier quoted context omitted.

Truncated SHA512 hashes, such as SHA512/256, defeat length extension attacks by omitting part of the hash state from the output. They're also significantly faster than classic SHA256 for large inputs.

Blake2/3 also doesn't suffer from length extension attacks, but SHA-256 is what everyone uses unfortunately.

We use Blake 3. So far so good…

Re: SHA-3 Buffer Overflow

#117

Post by adev_ »

manholio wrote: post #114
Donckele wrote: post #104

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.

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.

Re: SHA-3 Buffer Overflow

#118

Post by Cthulhu_ »

hot_gril wrote: post #107
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.

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.

Re: SHA-3 Buffer Overflow

#119

Post by raydiatian »

yieldcrv wrote: post #115

Bro what? This is a big deal right? Like NSO Group hacking everyone for the next 5 years deal?

> The vulnerable code was released in January 2011, so it took well over a decade for this vulnerability to be found.

It would have already been a big deal for the past five years, if anything.

Furthermore you have to induce a bufferoverflow first. I’m no security researcher, but to my mind that means you’re either (a) trusting idiots to write sensitive code without a IT Sec team reviewing it, or (b) you’ve got a malicious actor on the inside, who can slip it past review. I’m sure there are plenty of other scenarios, but I’m saying it doesn’t feel likely by gut.

Re: SHA-3 Buffer Overflow

#120

Post by hot_gril »

manholio wrote: post #114
Donckele wrote: post #104

“I’ve also shown how a specially constructed file can result in arbitrary code execution, ” Ouch, thats not looking good for a reference implementation for a piece of software deployed on billions and billions of machines that was written by experts and reviewed (and modified) by even bigger egg heads.

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.

What's to replace C, Rust?
Post reply on HN