3 ms·

Funny that this bug was discovered by rewriting it in Rust!

Pet_Ant 2y ago
I had to check if that was a meme joke or that is actually what happened, and it seems that it actually was found by rewriting it in Rust: > 2024-04-23 - Discovery of SSL_select_next_proto memory unsafety while rewriting it in rust. [ https://github.com/rustls/rustls-openssl-compat/tree/main/rustls-libssl https://github.com/rustls/rustls-openssl-compat/tree/main/ru... ]
MaxBarraclough 2y ago
Not the first time this kind of thing has happened. A rewrite in SPARK Ada uncovered a flaw in the reference C implementation of the Skein cryptographic algorithm. • https://www.adacore.com/press/spark-skein https://www.adacore.com/press/spark-skein (ctrl-f for flaw) • [PDF] https://www.cl.cam.ac.uk/archive/mjcg/Meeting.SecurityTools.2011/papers/sparkskein_fmats2011.pdf https://www.cl.cam.ac.uk/archive/mjcg/Meeting.SecurityTools.... (page 12) • [PDF] https://www.adacore.com/uploads/techPapers/SPARKSkein_SBMF.pdf https://www.adacore.com/uploads/techPapers/SPARKSkein_SBMF.p... (page 5)
tialaramex 2y ago
Specifically this is an attempted ABI compatibility layer. That is, given rustls, which is a perfectly nice Rust TLS implementation, what if we built the OpenSSL API and then shipped the C ABI compatible library ? In principle the result is definitely safe if your C code (which previously called OpenSSL) is safe, regardless of whether OpenSSL itself is riddled with bugs (which it likely is) A safety focused person rewriting tricky C pointer banging code in Rust is likely to inadvertently fix bugs - what's interesting is whether you notice that as you're doing it or it's just silently not buggy any more in Rust. A few hours ago I had some code that was doing bignum arithmetic and one call returned None where I hadn't realised it could and in a haze I thought "Oh, if it's None we can treat it as Zero" so I changed unwrap() to unwrap_or(Zero::zero()) † but nope, it was None because that function assumes we're getting integers and it's just figured out it has a proper fraction instead, so hence there is no such integer, None. Treating None as Zero meant all the related tests blew up and I realised my mistake after a couple of minutes. No, e to the power 0.5 is not 1. † Yes that's suboptimal because it will make the zero bignum even when it doesn't need it, I should have called unwrap_or_else instead but also no I shouldn't because it's wrong.
anthk 2y ago
Does this happen with LibreSSL?
- tadbit 2y ago
  No. They removed NPN support seven years ago. https://marc.info/?l=openbsd-announce&m=150996307120987&w=2 https://marc.info/?l=openbsd-announce&m=150996307120987&w=2

I had to check if that was a meme joke or that is actually what happened, and it seems that it actually was found by rewriting it in Rust: > 2024-04-23 - Discovery of SSL_select_next_proto memory unsafety while rewriting it in rust. [ https://github.com/rustls/rustls-openssl-compat/tree/main/rustls-libssl https://github.com/rustls/rustls-openssl-compat/tree/main/ru... ]

MaxBarraclough 2y ago

Not the first time this kind of thing has happened. A rewrite in SPARK Ada uncovered a flaw in the reference C implementation of the Skein cryptographic algorithm. • https://www.adacore.com/press/spark-skein https://www.adacore.com/press/spark-skein (ctrl-f for flaw) • [PDF] https://www.cl.cam.ac.uk/archive/mjcg/Meeting.SecurityTools.2011/papers/sparkskein_fmats2011.pdf https://www.cl.cam.ac.uk/archive/mjcg/Meeting.SecurityTools.... (page 12) • [PDF] https://www.adacore.com/uploads/techPapers/SPARKSkein_SBMF.pdf https://www.adacore.com/uploads/techPapers/SPARKSkein_SBMF.p... (page 5)

tialaramex 2y ago

Specifically this is an attempted ABI compatibility layer. That is, given rustls, which is a perfectly nice Rust TLS implementation, what if we built the OpenSSL API and then shipped the C ABI compatible library ? In principle the result is definitely safe if your C code (which previously called OpenSSL) is safe, regardless of whether OpenSSL itself is riddled with bugs (which it likely is) A safety focused person rewriting tricky C pointer banging code in Rust is likely to inadvertently fix bugs - what's interesting is whether you notice that as you're doing it or it's just silently not buggy any more in Rust. A few hours ago I had some code that was doing bignum arithmetic and one call returned None where I hadn't realised it could and in a haze I thought "Oh, if it's None we can treat it as Zero" so I changed unwrap() to unwrap_or(Zero::zero()) † but nope, it was None because that function assumes we're getting integers and it's just figured out it has a proper fraction instead, so hence there is no such integer, None. Treating None as Zero meant all the related tests blew up and I realised my mistake after a couple of minutes. No, e to the power 0.5 is not 1. † Yes that's suboptimal because it will make the zero bignum even when it doesn't need it, I should have called unwrap_or_else instead but also no I shouldn't because it's wrong.

anthk 2y ago

Does this happen with LibreSSL?

tadbit 2y ago
No. They removed NPN support seven years ago. https://marc.info/?l=openbsd-announce&m=150996307120987&w=2 https://marc.info/?l=openbsd-announce&m=150996307120987&w=2