Why don't we have linters that would complain about copying memory without bounds checking?
This shouldn't have happened: A vulnerability postmortem
121–130 of 499 posts
Re: This shouldn't have happened: A vulnerability postmortem
#122Earlier quoted context omitted.
FWIW, Go absolutely would not stop you writing unbounded data into a bounded struct. Idiomatic Go would be to use byte slices which auto-resize, unlike idiomatic C, but you still have to do it.
What's the exploit path assuming no use of unsafe? I can see situations where I could probably get go to crash, but not sure how I get go to act badly. Note: Not a go / Haskell / C# expert so understanding is light here.
Go is sometimes considered memory unsafe because of the presence of data races. (This is a controversial semantics.)
Re: This shouldn't have happened: A vulnerability postmortem
#123[deleted]
Re: This shouldn't have happened: A vulnerability postmortem
#124Earlier quoted context omitted.
Memory safe language that can compete with C/C++ in performance and resource usage is a new concept. AFAIK ADA guarantees memory safety only if you statically allocate memory, and other languages have GC overhead. Rust is really something new.
There's different classes of memory un-safety: buffer overflow, use after free, and double free being the main ones. We haven't seen a mainstream language capable of preventing use and free and double free without GC overhead until Rust. And that's because figuring out when an object is genuinely not in use anymore, at compile time, is a really hard problem. But a buffer overflow like from the article? That's just a…
> That's just a matter of saving the length of the array alongside the pointer and doing a bounds check, which a compiler could easily insert if your language had a native array type. Pascal and its descendants have been doing that for decades.
GCC has also had an optional bounds checking branch since 1995. [0]
GCC and Clang's sanitisation switches also support bounds checking, for the main branches, today, unless the sanitiser can't trace the origin or you're doing double-pointer arithmetic or further away from the source.
AddressSanitizer is also used by both Chrome & Firefox, and failed to catch this very simple buffer overflow from the article. It would have caught the bug, if the objects created were actually used and not just discarded by the testsuite.
Re: This shouldn't have happened: A vulnerability postmortem
#125Earlier quoted context omitted.
Go has an unsafe package. Is there an example of even "bad" go code that gets you from a overflow to an exploit? I'm curious, folks (usually rust folks) do keep making this claim, is there a quick example?
You can totally do this with bad concurrency in Go: read-after-write of an interface value may cause an arbitrarily bad virtual method call, which is somewhat UB. I am not aware of single goroutone exploits, though.
Concurrency issues / bad program flow feel a bit different don't they? I mean, I can store the action to take on a record in a string in any language, then if I'm not paying attention on concurrency someone else can switch to a different action and then when that record is processed I end up deleting instead of editing etc.
I mention this because in SQL folks not being careful end up in all sorts of messed up situations with high concurrency situations.
Re: This shouldn't have happened: A vulnerability postmortem
#126What went wrong - Issue #0: The library was not re-written in a language that prevents undefined behavior (UB).
Re: This shouldn't have happened: A vulnerability postmortem
#127Earlier quoted context omitted.
> This wasn’t a process failure, the vendor did everything right. Mozilla has a mature, world-class security team. They pioneered bug bounties, invest in memory safety, fuzzing and test coverage. Yep, definitely sounds like Project Zero is trashing Mozilla in this blog post.
They checked for process failure didn't they? Nobody will remember that line. Everyone is going to remember the title.
There's probably a disconnect between safety culture and PR culture here. It is true that this shouldn't have happened. It's extremely important to work out how to avoid it happening in a general sense. No-one here is angry at NSS or Mozilla. This safety culture pose reads to you as an attack because you're reading it in PR culture pose.
Re: This shouldn't have happened: A vulnerability postmortem
#128Earlier quoted context omitted.
The smallest binary rustc has produced is 138 bytes. It is true that it’s not something you just get for free, you have to avoid certain techniques, etc. But rust can fit just fine.
Do you have a link to an article / report about that 138 byte program? I'd be interested how to achieve that.
https://github.com/tormol/tiny-rust-executable got it to 137, but here's a blog post explaining the process to get it to 151: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...
Re: This shouldn't have happened: A vulnerability postmortem
#129Earlier quoted context omitted.
Actually, we are talking the creators of rust here. The same guys who were owning it with the idea to rewrite the entire browser in it. The more plausible reason might be that the rewrite to rust haven't advanced to this component yet.
Yeah, that could be. I was speaking about the wider development ecosystem. Rust is doing well in a few places and that's enough for it to survive and exist long term, or at least as long as Mozilla is relevant.
Mozilla's relevance hasn't mattered to Rust for a while.
Re: This shouldn't have happened: A vulnerability postmortem
#130Earlier quoted context omitted.
The smallest binary rustc has produced is 138 bytes. It is true that it’s not something you just get for free, you have to avoid certain techniques, etc. But rust can fit just fine.
Do you have a link to an article / report about that 138 byte program? I'd be interested how to achieve that.
I'd also like to see the smallest Rust binaries that are achieved by real projects. When the most size-conscious users use Rust to solve real problems, what is the result?