[HN Gopher] SHA-3 Buffer Overflow
___________________________________________________________________
SHA-3 Buffer Overflow
Author : cbzbc
Score : 89 points
Date : 2022-10-20 21:34 UTC (1 hours ago)
(HTM) web link (mouha.be)
(TXT) w3m dump (mouha.be)
| tinglymintyfrsh wrote:
| Oh shit. I better check my native Ruby extension that I believe
| uses the reference C code.
| bobkazamakis wrote:
| https://www.xilinx.com/products/intellectual-property/1-1mje...
|
| https://documentation-service.arm.com/static/62bb3e4bb334256...
| aliqot wrote:
| Interesting 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 by a commenter:
| The padding change is the only difference, this allows future
| tree hashing modes as well as the current SHAKE outputs to
| generate different digests given the same security parameters and
| message inputs. Up to 4 additional bits are added, which keeps
| the full padding inside a byte boundary, making implementations
| with octet only input able to switch to SHA-3 from Keccak with
| change to only a single line of code.
|
| https://crypto.stackexchange.com/questions/10645/are-nists-c...
|
| https://cdt.org/insights/what-the-heck-is-going-on-with-nist...
|
| ketccak team's response:
| https://keccak.team/2013/yes_this_is_keccak.html
| encryptluks2 wrote:
| It wouldn't be the first time NIST has got doing nefarious
| things
| tptacek wrote:
| 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.
| aliqot wrote:
| 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
| jbirer wrote:
| Appeal to Authority is not a very good argument either.
| arisAlexis wrote:
| Can someone ELI5 the severity of this over the whole internet?
| What breaks/what not
| flatiron wrote:
| If you don't use that library then nothing. If you do and you
| hash my crafted binary I probably could crash it.
| Ayesh wrote:
| SHA3 is relatively infrequent compared to sha1/2 and md5. SHA3
| also has a few variants, and I don't know for sure if this
| vulnerability is present in all variants.
|
| The vulnerability is only present in the reference
| implementation. So it's unlikely that other implementations
| (rush as Rust or Go) are vulnerable.
|
| I tested with the latest released and master branches of PHP,
| both of which segfaulted for the code samples mentioned in the
| article. The article says Python is also vulnerable.this is
| because both of the languages apparently use the reference
| implementation.
|
| Ethereum uses SHA3 quite extensively, but I doubt it's
| vulnerable post migration from PoW, let alone it's unlikely
| that they use the vulnerable implementation/variant.
| flatiron wrote:
| So if we ported this library to rust sha3 seems peachy? No doubt
| an interesting port but it now seems inevitable.
| brundolf wrote:
| > The vulnerable code was released in January 2011, so it took
| well over a decade for this vulnerability to be found
|
| Ouch
| galangalalgol wrote:
| 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 rely on thos
| software's security. It's paid for by people that rely on it's
| insecurity. So we don't know about this stuff until they or the
| people they sold it too use these exploits.
|
| Edit: in case the solution I propose isn't obvious,
| organizations like red hatand google need to pay for these
| pipelines and unit tests. Getting good unit test coverage is
| expensive and ubsan and asan don't work without that coverage.
| 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. Well, maybe formal analysis?
| lmm wrote:
| > 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.
| galangalalgol wrote:
| 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.
| [deleted]
| ajsfoux234 wrote:
| The vulnerability impacts 'the "official" SHA-3 implementation'.
| How widely used is it for SHA-3 hashing compared to something
| like OpenSSL?
| duskwuff wrote:
| SHA-3 is rarely used in general. Most applications still use
| SHA-2 hashes (such as SHA256).
| derefr wrote:
| 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/ma
| ster/sha3/keccakf_am...).
|
| Slightly concerning news for the (mostly-Golang-based) Ethereum
| ecosystem, which relies on SHA3-256 for pretty much
| everything...
| tptacek wrote:
| 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.
| derefr wrote:
| 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.
|
| Maybe the Golang runtime isn't allocating you precisely as
| many bytes as you're asking for, but rather a little bit
| more? Rounding up to a multiple of a page for more-than-
| page-sized allocations?
| cipherboy wrote:
| Does this impact most distros? I'd imagine Python and PHP's
| native crypto bindings would be replaced with OpenSSL which
| should have assembly variants of SHA-3.
| ok_dad wrote:
| I use pyenv and whatever it installed for 3.10.4 months ago
| seems to be fine with the example code snippet run in the
| console. It took a few seconds, but didn't crash.
| metadat wrote:
| If you're familiar with SHA-256 and this is your first encounter
| with SHA-3:
|
| The main differences between the older SHA-256 of the SHA-2
| family of FIPS 180, and the newer SHA3-256 of the SHA-3 family of
| FIPS 202, are:
|
| * Resistance to length extension attacks.
|
| * Performance. The SHA-2 functions--particularly SHA-512,
| SHA-512/224, and SHA-512/256--generally have higher performance
| than the SHA-3 functions. Partly this was out of paranoia and
| political reasons in the SHA-3 design process.
|
| Further reading:
| https://crypto.stackexchange.com/questions/68307/what-is-the...
| moonchild wrote:
| My understanding was that sha-3 should be faster than sha-2, in
| a general sense, but sha-2 has hardware acceleration. Is that
| incorrect?
| Vecr wrote:
| I think SHA-3 is almost always slower in software, in theory
| SHA-3 could be hardware accelerated of course, but on both
| current AMD and Intel systems it's not, where SHA-2-256 is.
| a-dub wrote:
| i thought sha-2 included the message length in the head padding
| to prevent length extension attacks?
|
| just read the link you provided: it's sha-224 and above.
|
| i wonder if a similar issue exists in the sha-224+ padding
| code.
___________________________________________________________________
(page generated 2022-10-20 23:00 UTC)