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

21–30 of 186 posts

Re: SHA-3 Buffer Overflow

#21

Post by lmm »

galangalalgol wrote: post #15
brundolf wrote: post #12

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

Between this and "beacown" I came to a realization. I work on codebases worth way less than these amd we do lots of different static analyzers two compilers, lots of unit tests with coverage checks and asan/ubsan. The linux kernel and sha are worth tons of money. Thus, someone wrote all the pipelines and unit tests for that software too. The problem is, the people who paid for all that work aren't the people that rel…

> 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.

Re: SHA-3 Buffer Overflow

#23

Post by tptacek »

derefr wrote: post #17
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?

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...

Easy enough to test, right?

    func main() { 
      h := sha3.New224()
      buf := make([]byte, 4294967295)
      h.Write(buf)
      sum := h.Sum(nil)
      fmt.Printf("%x\n", sum)
    }
Doesn't crash on my amd64 dev machine.

Later

I could have just looked at the code, too: the assembly you've linked to is just the Keccak permutation, not the entire Go hash; the buffer management is done in Go, not in assembly.

Re: SHA-3 Buffer Overflow

#24

Post by galangalalgol »

lmm wrote: post #21
galangalalgol wrote: post #15

Earlier quoted context omitted.

Between this and "beacown" I came to a realization. I work on codebases worth way less than these amd we do lots of different static analyzers two compilers, lots of unit tests with coverage checks and asan/ubsan. The linux kernel and sha are worth tons of money. Thus, someone wrote all the pipelines and unit tests for that software too. The problem is, the people who paid for all that work aren't the people that rel…

> 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.

Re: SHA-3 Buffer Overflow

#25

Post by duskwuff »

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).

Re: SHA-3 Buffer Overflow

#26

Post by aliqot »

tptacek wrote: post #20
encryptluks2 wrote: post #16

Earlier quoted context omitted.

Quoted post unavailable.

You're responding to a post that links to the Keccak designers saying that the padding change isn't nefarious. You have to be able to do better than "NIST bad" in comments on threads like these.

From Daniel J. Bernstein:

2022.08.05: NSA, NIST, and post-quantum cryptography: Announcing my second lawsuit against the U.S. government. : https://blog.cr.yp.to/20220805-nsa.html

https://twitter.com/hashbreaker/status/1555625577989541888

Re: SHA-3 Buffer Overflow

#27

Post by derefr »

tptacek wrote: post #23
derefr wrote: post #17

Earlier quoted context omitted.

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...

Easy enough to test, right? func main() { h := sha3.New224() buf := make([]byte, 4294967295) h.Write(buf) sum := h.Sum(nil) fmt.Printf("%x\n", sum) } Doesn't crash on my amd64 dev machine. Later I could have just looked at the code, too: the assembly you've linked to is just the Keccak permutation, not the entire Go hash; the buffer management is done in Go, not in assembly.

This is one of those cases where I'm actually more concerned that it doesn't crash. It's like seeing clearly-syntactically-invalid code that somehow compiles anyway — you wonder what semantics the compiler could have possibly ascribed to it.

Presumably this isn't not-crashing just because the developers of the Golang stdlib somehow found+fixed this bug back in 2015 when this assembler file was baked. The error is in that assembler code, I'm sure. It's presumably getting masked by something. (Something that may be benign, or might be subtly corrupting the runtime.)

For a benign case: maybe the Golang runtime isn't allocating you precisely as many bytes as you're asking for, but rather a little bit more? Perhaps rounding up to a multiple of a page for more-than-page-sized allocations?

Not having access to an amd64 machine at the moment, I'll have to ask you: does increasing the size by one, as in the article, cause an infinite loop?

Re: SHA-3 Buffer Overflow

#28

Post by jbirer »

tptacek wrote: post #20
encryptluks2 wrote: post #16

Earlier quoted context omitted.

Quoted post unavailable.

You're responding to a post that links to the Keccak designers saying that the padding change isn't nefarious. You have to be able to do better than "NIST bad" in comments on threads like these.

Appeal to Authority is not a very good argument either.

Re: SHA-3 Buffer Overflow

#29

Post by ouid »

What 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?
Post reply on HN