This sounds like a very good argument for switching over to Rust.
Genuine question: How to switch codes written in 2003 to Rust?
Slowly and steadily.
This shouldn't have happened: A vulnerability postmortem
11–20 of 499 posts
Re: This shouldn't have happened: A vulnerability postmortem
#12This sounds like a very good argument for switching over to Rust.
Genuine question: How to switch codes written in 2003 to Rust?
Maybe this is not so much about switching individual existing projects to Rust, but about switching the "industry".
Some new projects are still written in C.
Re: This shouldn't have happened: A vulnerability postmortem
#13Wow.
We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure?
And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare).
My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits.
Is there a point at which someone says, hey, if it's very security sensitive write it in a language with a GC (golang?) or something crazy like rust? Or are C/C++ benefits just too high to ever give up?
And similarly, that simplicity is a benefit (ie, BoringSSL etc has some value).
Re: This shouldn't have happened: A vulnerability postmortem
#14This sounds like a very good argument for switching over to Rust.
Genuine question: How to switch codes written in 2003 to Rust?
The same way you would write code written in 2021 over to Rust: by rewriting it from the ground up.
Auto-translation won't work because Rust won't allow you to build it in the same way you would have built it in C. It requires a full up redesign of the code to follow the Rust development model.
Re: This shouldn't have happened: A vulnerability postmortem
#15Buffer Overflow is a classic right? (queue Rust enthusiasts)
It's wild how ahead of it's time Ada was.
Re: This shouldn't have happened: A vulnerability postmortem
#16Re: This shouldn't have happened: A vulnerability postmortem
#17Wow. We continue to be reminded that it's hard to write fully memory secure code in a language that is not memory secure? And by hard, I mean, very hard even for folks with lots of money and time and care (which is rare). My impression is that Apple's imessage and other stacks also have memory unsafe languages in the api/attack surface, and this has led to remote one click / no click type exploits. Is there a point a…
It's hard to fault a project written in 2003 for not using Go, Rust, Haskell, etc... It is also hard to convince people to do a ground up rewrite of code that is seemingly working fine.
Re: This shouldn't have happened: A vulnerability postmortem
#18Buffer Overflow is a classic right? (queue Rust enthusiasts)
"This shouldn't have happened," says user of the only language where this regularly happens. https://www.theonion.com/no-way-to-prevent-this-says-only-na...
Yep, Rust at best eliminates some already weak excuses to keep doing security critical parsing in the chainsaw-juggling traditon, when we've known better for 20+ years.
Re: This shouldn't have happened: A vulnerability postmortem
#19This sounds like a very good argument for switching over to Rust.
More than just one memory safe language
Re: This shouldn't have happened: A vulnerability postmortem
#20A title that actually describes the post, mostly paraphrasing the first paragraph: Reasons why this buffer overflow wasn't caught earlier despite doing all the right things And then to give those reasons: - "each component is fuzzed independently" ... "This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could ne…
> - "There is an arbitrary limit of 10000 bytes placed on fuzzed input. There is no such limit within NSS; many structures can exceed this size. This vulnerability demonstrates that errors happen at extremes"
This is the one that seemed short sighted to me. It's a completely arbitrary (and small!) limit that blinded the fuzzer to this very modest sized buffer overflow.