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.
SHA-3 Buffer Overflow
91–100 of 186 posts
Re: SHA-3 Buffer Overflow
#92Earlier 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.
> 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 you lower your defect rate; it's that it lets you maintain your existing (acceptable) defect rate at a much lower cost, by letting you drop your static analysis and most of your tests (reducing maintenance burdens) and still have a better bottom-line defect rate.
Re: SHA-3 Buffer Overflow
#93The vulnerability impacts 'the "official" SHA-3 implementation'. How widely used is it for SHA-3 hashing compared to something like OpenSSL?
The version in the Golang stdlib defaults to a pure-go implementation... unless you're compiling for amd64, in which case you get an assembler variant apparently directly derived from the XKCP package ( https://github.com/golang/crypto/blob/master/sha3/keccakf_am... ). Slightly concerning news for the (mostly-Golang-based) Ethereum ecosystem, which relies on SHA3-256 for pretty much everything...
All the Go code is safe. No bugs.
Re: SHA-3 Buffer Overflow
#94It 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.
And even if they are, you probably aren't going to do a digest on the whole thing all at once.
Re: SHA-3 Buffer Overflow
#95SHA-3 in Ruby: $ gem install sha3 $ irb > require 'sha3' > s = SHA3::Digest::SHA224.new > s.update("\x00") > s.update("\x00" * 4294967295) [ Segmentation fault... ] Tested with Ruby 3.1.2 Gem's code (including C native extension): https://github.com/johanns/sha3
Just over half a million total downloads. So some use but not particularly popular.
Re: SHA-3 Buffer Overflow
#96What dows generating preimages mean here? The preimage is the set of all messages that hash to some set of hashes. Is the author saying the the hash function is reversible in reasonable time?
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
Re: SHA-3 Buffer Overflow
#97no bounty and still politely reports it. Good guys need more praise.
it's a public standard, who would pay such a bounty?
A couple companies sponsor “the internet bug bounty”: https://www.hackerone.com/internet-bug-bounty
IMHO, sha3 should be part of that bounty.
Re: SHA-3 Buffer Overflow
#98Interesting 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…
[deleted]
Re: SHA-3 Buffer Overflow
#99no bounty and still politely reports it. Good guys need more praise.
[deleted]
Re: SHA-3 Buffer Overflow
#100Interesting 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…
[deleted]
[deleted]