Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust’s standard library was vulnerable for years and nobody noticed

medium.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Rust’s standard library was vulnerable for years and nobody noticed

#41

Post by rurban »

cdoxsey wrote: post #9

In Go you can write unsafe code in libraries. You can even write raw assembly if you want. We had an encoding library written in a very c-ish style for maximum performance, and sure enough, it had an off-by-one error on the last byte that could've been exploited. It's funny that in severely limiting the area we could use unsafe we still somehow managed to write it improperly. If anything it serves as a reminder of wh…

> If anything it serves as a reminder of why memory safety is so critical and Rust was right to focus on it from the beginning

So why did they gave up on memory safety then and ditched their GC? Relying on alloca only has limited use cases, esp. with threads with their severe stack limits.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#42

Post by steveklabnik »

rurban wrote: post #41
cdoxsey wrote: post #9

In Go you can write unsafe code in libraries. You can even write raw assembly if you want. We had an encoding library written in a very c-ish style for maximum performance, and sure enough, it had an off-by-one error on the last byte that could've been exploited. It's funny that in severely limiting the area we could use unsafe we still somehow managed to write it improperly. If anything it serves as a reminder of wh…

> If anything it serves as a reminder of why memory safety is so critical and Rust was right to focus on it from the beginning So why did they gave up on memory safety then and ditched their GC? Relying on alloca only has limited use cases, esp. with threads with their severe stack limits.

Rust did not give up on memory safety, nor does rust support alloca.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#43

Post by [deleted] »

acdha wrote: post #39
heavenlyblue wrote: post #37

Earlier quoted context omitted.

So what’s more important, to be secure or to ship, then? I think people made their choice and the developers of the said maps are not responsible for whatever comes out of map’ lack of security.

Those aren't the only options. A key part of the original comment was “in its standard library” — in the modern era where package managers have existed for decades, it's quite reasonable to develop things in separate projects and only pull them into the standard library when they're more stable. That allows people to use them without giving the weight of being in the standard library. Similarly, you could require som…

[deleted]

Re: Rust’s standard library was vulnerable for years and nobody noticed

#44

Post by stfwn »

debiandev wrote: post #30
stfwn wrote: post #8

TLDR: presumably 2 y/o (10 Jul '15) segfault bug in stdlib was discovered, fixed and merged into master on the same day on 27 Sept '17. Next release was 12 Okt '17, 15 days later. OP argues the bug should have been filed into the CVE [0] so that people who run old versions of Rust know about it and can act accordingly. [0]: https://en.m.wikipedia.org/wiki/Common_Vulnerabilities_and_E... Personally I'd say running old…

The opposite is true: new vulnerabilities can be introduced in new feature releases, while older releases can receive backported security fixes. That means that the level of security of a well maintained stable release train can only increase over time. This is why Debian puts so much effort in freezing and baking the distribution and backporting security fixes.

Good points, thank you. This did change my perspective.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#46

Post by rurban »

steveklabnik wrote: post #42
rurban wrote: post #41

Earlier quoted context omitted.

> If anything it serves as a reminder of why memory safety is so critical and Rust was right to focus on it from the beginning So why did they gave up on memory safety then and ditched their GC? Relying on alloca only has limited use cases, esp. with threads with their severe stack limits.

Rust did not give up on memory safety, nor does rust support alloca.

Isn't it a bit unfortunate that you have no idea about your own project.

Internally rust stack allocates most local objects, but it's size is unchecked. see eg. https://github.com/rust-lang/rust/issues/48055

2nd rust had memory safety in early 0.x releases with a proper GC, but it was removed. Now you either have to manually check local objects sizes or handle global refs manually or use unsafe and unhandled memory allocation for custom aggregates. The stdlib is full of such. nobody can declare memory safety for rust, only you, but unfortunately you exhausted your credibility long time ago. Also with your claim of concurrency safety ("then don't use mutexes"). rust is a fine languages, you don't need to lie about its properties. the docs need to remove false claims, and you seriously need to stop overhyping it.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#47

Post by steveklabnik »

rurban wrote: post #46
steveklabnik wrote: post #42

Earlier quoted context omitted.

Rust did not give up on memory safety, nor does rust support alloca.

Isn't it a bit unfortunate that you have no idea about your own project. Internally rust stack allocates most local objects, but it's size is unchecked. see eg. https://github.com/rust-lang/rust/issues/48055 2nd rust had memory safety in early 0.x releases with a proper GC, but it was removed. Now you either have to manually check local objects sizes or handle global refs manually or use unsafe and unhandled memory a…

Note that RFC is not implemented and not stable; this means it’s not in Rust.

If you can find memory unsafety in safe Rust, it would be a huge deal. Please file bugs. That doesn’t seem to be what you’re saying, though.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#48

Post by rurban »

steveklabnik wrote: post #47
rurban wrote: post #46

Earlier quoted context omitted.

Isn't it a bit unfortunate that you have no idea about your own project. Internally rust stack allocates most local objects, but it's size is unchecked. see eg. https://github.com/rust-lang/rust/issues/48055 2nd rust had memory safety in early 0.x releases with a proper GC, but it was removed. Now you either have to manually check local objects sizes or handle global refs manually or use unsafe and unhandled memory a…

Note that RFC is not implemented and not stable; this means it’s not in Rust. If you can find memory unsafety in safe Rust, it would be a huge deal. Please file bugs. That doesn’t seem to be what you’re saying, though.

This issue outlines one of the problems with memory safety which is not fixed. Since you don't believe outsiders, look at your own tickets, where your own developers admit unsafety. There are probably more, this is just the first I found.

But the general problem is that rust cannot be made memory safe at all with its current architecture. Overlarge alloca calls are unsafe by default (either accept compile-time failures or accept run-time stack failures on new threads), and the strategy with global containers and references into it is unsafe. Even when rust would remove its unsafe keyword, and disallow malloc via ffi. Maybe you should fix your attitude towards your unsafeties.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#49

Post by leshow »

zozbot123 wrote: post #32
leshow wrote: post #24

This article casually throws around definitions of 'memory safety' that are massively different. Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Rust includes protection from things like modifying memory from 2 different spots at the same time, among other things. AFAIK that's perfectly fine to do in Go, you can pass around pointers between threads as much as you like. This sort of behaviour…

> Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Nope. Rust protects against data races, that are universally considered memory unsafe, given the usual C/C++ concurrency model. There is no ambiguity here. And yes, sequential Go _is_ memory safe, but concurrent Go is not. Deal with it, gophers - and please do not impute purposeful ambiguity and disingenuous characterization where there isn't…

> And yes, sequential Go _is_ memory safe, but concurrent Go is not.

You're agreeing with me, I was saying that Go isn't memory safe by Rusts definition. As you mentioned, it doesn't protect against data races, therefore, when Go claims memory safety they are using some different definition of memory safe.

Re: Rust’s standard library was vulnerable for years and nobody noticed

#50

Post by leshow »

vanderZwan wrote: post #28
leshow wrote: post #24

This article casually throws around definitions of 'memory safety' that are massively different. Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Rust includes protection from things like modifying memory from 2 different spots at the same time, among other things. AFAIK that's perfectly fine to do in Go, you can pass around pointers between threads as much as you like. This sort of behaviour…

> I just really don't understand the criticism against Rust here I think you are confusing two different narratives in the article: software development in general, and Rust the language/ecosystem/community. The article raises many points about how the former as a whole does not care enough about security. How we do not have the right incentives to fix memory safety bugs (the bug bounty thing) nor treat them as the s…

> "unsafe" by definition throws safety guarantees out the window

I wish they had chosen a different keyword, it doesn't necessarily mean that. For instance, the type checker still runs on the contents of unsafe blocks, so does the borrow checker, the only thing you can do that you can't normally is dereference raw pointers. This is potentially unsafe, and you should be careful, but it absolutely does not "throw all guarantees out the window".

Post reply on HN