4 ms·

So if we ported this library to rust sha3 seems peachy? No doubt an interesting port but it now seems inevitable.

tialaramex 4y ago
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 life. A more specialised language like WUFFS doesn't write bounds checks, it just constrains all the buffer access variables, so when you write code that could overflow that doesn't compile, preventing this problem. There is a price for this, you can have code which you know, intellectually, never hits the case where say k = 5, but maybe the proof would be sixty pages of difficult maths, WUFFS just won't compile that code until you add handling for k = 5, too bad, safe Rust insists on behaving as though k might be 5 (e.g. inserting runtime checks), unsafe Rust would allow you to YOLO, with a lot of hoop jumping, C++ doesn't care. Of course if your sixty page proof is wrong then these outcomes feel very different...
- green_on_black 4y ago
  It seems that some memory safety bug in C/C++ makes HN frontpage every other day.
tinglymintyfrsh 4y ago
Not the same, but there are multiple implementations. Here's the top one with 13 M downloads. https://crates.io/crates/sha3 https://crates.io/crates/sha3 If someone used ffi, linked to it, or attempted to reproduce the behavior verbatim in unsafe code, obviously it would have the same problems as the native code.
drexlspivey 4y ago
what do you mean? the sha3 crate is 8 years old
wongarsu 4y ago
Rust code already exclusively uses rust ports of the library. There are a couple competing ones [1][2], but I couldn't even find rust bindings for the official C library. The ecosystem has a bit of a fetish for pure rust dependencies where possible, and this vulnerability seems to vindicate that stance. I don't think any of those are published as libraries usable by other languages, but doing that would be less than a hundred lines for defining a C interface. 1: https://lib.rs/crates/sha3 https://lib.rs/crates/sha3 2: https://lib.rs/crates/tiny-keccak https://lib.rs/crates/tiny-keccak
- oconnor663 4y ago
  I maintain some Rust bindings to the official implementation here: https://crates.io/crates/kangarootwelve_xkcp https://crates.io/crates/kangarootwelve_xkcp. I've published an update with today's patch (https://github.com/XKCP/K12/commit/27a84ecb811200990add07a047214f4ee7f77d48 https://github.com/XKCP/K12/commit/27a84ecb811200990add07a04...). That said, I don't know whether those overflows were exploitable with K12.

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 life. A more specialised language like WUFFS doesn't write bounds checks, it just constrains all the buffer access variables, so when you write code that could overflow that doesn't compile, preventing this problem. There is a price for this, you can have code which you know, intellectually, never hits the case where say k = 5, but maybe the proof would be sixty pages of difficult maths, WUFFS just won't compile that code until you add handling for k = 5, too bad, safe Rust insists on behaving as though k might be 5 (e.g. inserting runtime checks), unsafe Rust would allow you to YOLO, with a lot of hoop jumping, C++ doesn't care. Of course if your sixty page proof is wrong then these outcomes feel very different...

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

tinglymintyfrsh 4y ago

Not the same, but there are multiple implementations. Here's the top one with 13 M downloads. https://crates.io/crates/sha3 https://crates.io/crates/sha3 If someone used ffi, linked to it, or attempted to reproduce the behavior verbatim in unsafe code, obviously it would have the same problems as the native code.

drexlspivey 4y ago

what do you mean? the sha3 crate is 8 years old

wongarsu 4y ago

Rust code already exclusively uses rust ports of the library. There are a couple competing ones [1][2], but I couldn't even find rust bindings for the official C library. The ecosystem has a bit of a fetish for pure rust dependencies where possible, and this vulnerability seems to vindicate that stance. I don't think any of those are published as libraries usable by other languages, but doing that would be less than a hundred lines for defining a C interface. 1: https://lib.rs/crates/sha3 https://lib.rs/crates/sha3 2: https://lib.rs/crates/tiny-keccak https://lib.rs/crates/tiny-keccak

oconnor663 4y ago
I maintain some Rust bindings to the official implementation here: https://crates.io/crates/kangarootwelve_xkcp https://crates.io/crates/kangarootwelve_xkcp. I've published an update with today's patch (https://github.com/XKCP/K12/commit/27a84ecb811200990add07a047214f4ee7f77d48 https://github.com/XKCP/K12/commit/27a84ecb811200990add07a04...). That said, I don't know whether those overflows were exploitable with K12.