Hacker News Reader

Comment by 1f60c | Hacker News Reader

Is this “just” a 20% project or is this more significant (like Android one day supporting Rust to develop apps)?

And I haven’t looked at everything yet, but it suggests to install Rust like this:

  sudo apt install cargo rust-src

While everyone I know uses rustup^:

  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

^ https://rustup.rs/

View on HN

Hi, I wrote the course :-) Yes, this is a real thing — Android has had support for Rust in the Android Platform for a few years now. Most recently, we shipped support for DNS-over-HTTP/3: https://security.googleblog.com/2022/07/dns-over-http3-in-an...

We put out the course to make it easy for even more people to onboard with Rust.

Rust does not guarantee that there are no memory leaks, you can have things reference eachother and therefore never count to 0. This is why weak pointers exist in rust.

It does not guarantee, but it is actually quite hard to cause a memory leak by accident, because at the same time Rust makes creating cycles hard.

I actually haven't tried this... do you know off the top of your head what it takes to make a cycle with Rc?

It should not be possible with normal borrows (and safe Rust) since they're statically checked to be acyclic.

You could store a `RefCell<Option<T>>` in an `Rc` and set it to `Some(rc)` after creation.

Or you could use the recently-stabilized `new_cyclic` method: https://doc.rust-lang.org/std/rc/struct.Rc.html#method.new_c...

The Rust Book has an example: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Of course, leaking memory is as easy as using `Box::leak`, although that's probably never going to happen accidentally.

And when using C libraries / FFI, there are a lot of tricky things going in, it is much easier to leak in unsafe land.

You're incorrect, sorry. It's very easy to creat cycles in inner-mutable data structures (e.g. Rc).

Right, this is a problem with reference counted data structures in general. You're correct that Rust doesn't try to solve this particular problem.

Put differently, the borrow checker won't allow you to create a cycle of refrences (the & kind). But you can do it with library types such as Rc.

It's a property of basic RC but real-world RC based GC systems can often collect reference cycles. For example Python and PHP do this.

(I'm sure you knew this, just adding to the discussion)

Rust doesn’t though. But it does make it much harder to leak memory than C. You need to create a cycle between reference counted objects versus just forget to free something.

Not that it matters as much as people think. Memory leaks aren’t a correctness problem. You typically want to restart a program or service regularly anyway to deal with memory fragmentation. You also frequently have a watchdog like systemd to restart your program if it crashes. Heroku restarts your whole dyno once a day. This means in practice that programs with slow memory leaks tend to work just fine (there are plenty of them in the wild.)

Interesting view that memory leaks aren't correctness problems. But I would require more convincing to agree.

It's true that memory leaks can be small enough that they don't become problems in the end-to-end behaviour of the system in regular use. But a lot of bugs are like that. For example many memory safety bugs.

> Interesting view that memory leaks aren't correctness problems.

The view of rust is rather that they’re not safety problems.

Whether they’re correctness problems is more complicated: in general they are, but there are lots of cases where they’re not, like short-running processes (once the process terminated it’s memory is reclaimed so freeing it is unnecessary overhead), or FFI (you’re moving memory out of your purview, you can’t know whether it’ll be disposed of anymore).

Safety and security as terms have an interesting relationship especially in Rust context - traditionally in engineering safety means defending against accidents and security means defending against malicious attackers, but "safety" in the term "memory safety" commonly implies security as well. Language is hard...

Considing whether memory leaks are a security problem brings us to the traditional CIA definition of security - the A (availability) is at risk from memory leaks.

Sorry, I should have said they’re not safety problems. The commenters below got it right.

Memory safety bugs are very different, because whether or not they affect the functioning of your software, they’re a ticking time bombs that could compromise your system. A memory leak will at worst crash your software.

> Is this “just” a 20% project or is this more significant (like Android one day supporting Rust to develop apps)?

Android already uses Rust internally, in fact for new code it's a major language. They have made this guide to teach Rust to their engineers working on Android, according to this post on reddit: https://old.reddit.com/r/rust/comments/zrs1of/new_rust_cours...

I'm tired of installation instructions that consist of "curl | sh". Especially since this one just tries to detect the platform and downloads the correct installer for me. I know what platform I'm running, and I don't want to pipe the internet to my shell. In the end this is unpacking a tarball in ~/.rustup, I don't need the risk of running some bespoke script for that.

On some distros you can install rustup directly, e.g. NixOS or Arch. For Ubuntu, it's sadly not in the default repositories, but there is a snap for rustup uploaded by the rustup maintainer.

https://pkgs.org/search/?q=rustup

https://snapcraft.io/rustup

Since the ultimate objective is to run a binary blob that you just downloaded off of the internet, piping a script to your shell over HTTPS adds no additional attack surface.

I get what you are trying to say here but I could also make the argument that you actually doubled it because now you have to trust two things rather than one.

Depending on how you want to consider trust in a wider sense too it may even be worse than “double” because I do not have the same amount of trust for the package I am ultimately installing and the script I am using to install it.

Edit: it’s actually 3 things you need to trust I didn’t include curl itself which just released a security audit that found a number of vulnerabilities here https://daniel.haxx.se/blog/2022/12/21/the-2022-curl-securit...

…security is often harder than it looks.

> now you have to trust two things rather than one

No, you're still trusting one thing: the host itself. You're downloading both the script and the binary from the host. Both could be backdoored, and of the two, the binary is far easier to hide a backdoor in.

As for not trusting curl, you still need to fetch the resource somehow, so you're going to be trusting some tool to do it for you. That's not relevant to increasing the attack surface.

I’m not actually in the Rust ecosystem at all and only just discovered the domain belongs to the official Rust project.

That clearly changes the trust calculation in this scenario.

I had assumed it was some 3rd party project which would have put it in a different category of problems entirely.

But the entire conversation is kind of pointless then. “There is a secret backdoor in the official Rust binary” is not a useful part of any reasonable threat model.

> You're downloading both the script and the binary from the host.

Technically, if you don’t read the script, you don’t know the binary is from the same host.

That doesn’t matter, though. The chain of trust is deep, including the tooling that produced the binary, your CPU, the internet, etc.

Downloading the first file basically says “I trust this site to give me this tool and nothing else”. Where it then gets that stuff from shouldn’t matter, even if it is from a shady site. You trusted them not to do that, just as you trusted them not to open up their own site so that hackers can replace files ont it.

Actually no, one can detect curl-piping server-side and serve hostile blobs only to those foolish enough to do so: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

And kibwen's point is that if you're in a situation where you're running potentially hostile binaries from a remote host, the fact that you used `curl | sh` to obtain said binary is not the pressing problem.

I'm well aware of that attack, it's quite cute, but if you don't trust the host not to serve you a backdoored binary then you've already lost.

And where is this trust supposed to come from? I downloaded the thing manually, looked at the scripts, ran the binary in a sandbox, it seemed to be OK. Right, I'll recommend that everyone just curl | bash's it ...

I think the worst thing about this is that Rust is fashionable, so encouraging inexperienced devs think that these dangerous practices are just fine. Look around at how many n00b projects now suggest doing exactly the same thing. It's simply irresponsible of the Rust crowd to keep promoting it.

The bash timing exploit makes everyone focus just on how cleverly evil it can be, and forget the big picture that it's about trusting the Rust org not to screw you.

(BTW, you can run `curl | sh` in a VM or with a modified bash to intercept the code and catch the bash script in the act, so it's not actually as sneaky as people believe).

If you think the Rust org is going to pwn you in a clever sneaky way, then you can't use Rust or any Rust-containing products.

In the end, you're pulling hundreds of MBs of binaries that you won't review, they're compiled from over 15 million lines of code that I don't believe you'd ever review either. Reviewing just the first 10 lines of code gives you nothing. A smoke test in a sandbox is also worthless, since a binary could detect being run that way, or delay the attack, or attack by specifically miscompiling your code (see Reflections on Trusting Trust).

In the end, you have to trust the Rust org, all of it.

"Trusting the Rust org not to screw you" is one part, another part is trusting the Rust server operators to defend against server compromise by any third party. So trusting the intentions is not sufficient.

The same thing applies to any binaries downloaded from their site, so unless you you've got signed binaries (that use an independently obtained/verified chain of trust), trusting the server is your your only option. Even with signed binaries, you're still trusting the entity that holds the signing key.

In real world trust is not so binary. In a risk assessment I'd be interested evaluating the level of assurance there is in the supply chain of how you get your binaries and artifacts. Some of it can be done using crypto like you say, some of it could be eg published audit reports from a reputable evaluator or other credible information about the processes.

I call this the "Lie back and think of England" stance.

You're not wrong, until the end, it should be: "you have to distrust the Rust org, all of it."

And not just Rust, Python and JS and all the others. There are languages and systems that take trust and security seriously, but these are not they.

Pray tell us, which languages do take trust and security seriously, according to you?

(Is it that you don't know of any yourself? Or that you think I can't provide examples? In what world is what I said even slightly controversial? Type checking is just catching on now, decades after it was invented and implemented. C'mon.)

Anyway, off the top of my head, Ada.

https://en.wikipedia.org/wiki/Ada_(programming_language)

and E...

https://en.wikipedia.org/wiki/E_(programming_language) https://en.wikipedia.org/wiki/CapROS

Qubes and SEL4 are Operating systems. (OK Labs was acquired by General Dynamics. That seems like a pretty good recommendation to me.)

https://en.wikipedia.org/wiki/Qubes_OS

https://en.wikipedia.org/wiki/L4_microkernel_family#High_ass...

Changing nothing about the relative security of using curl | sh.

also by doing that you don't keep a copy of the script for investigation if something smells fishy later

You can't check the hash of something you immediately piping to your shell, for example.

Checking the hash isn't relevant here. The content is served via HTTPS, you either trust the host or you don't. A host can easily serve you a malicious binary, as well as the valid hash of that malicious binary.

Which is why many people choose to only install software from their trusted distro maintainers who add a layer of vetting for random software packages, often built from source so messing with the package isn't possible without leaving some kind of trace that can be detected later.

Indeed, by all means, prefer to trust your distro if they package a version that's new enough. Alternatively, prefer to build from source if you like. But if you trust the Rust project to be competent enough and benign enough not to include malware in the compiler itself, then it's not a stretch to trust their official toolchain juggling tool downloaded from their official website. Focusing on the curl | bash aspect is a tired meme at this point.

Your distro's overworked maintainer isn't reviewing 15+ million lines of code included in Rust.

Most likely they get the precompiled rustc binary just like rustup, and LGTM-YOLO the package. If they try to be diligent, they maybe take extra 150K lines of mrustc code they can't reasonably carefully review for backdoors either, and then use it to bootstrap the several sets of 15M lines of code they won't look at.

The one thing you may get in using your distribution is protection for the case that the rustup.sh website has been temporarily pwned. But I agree that focusing on curl | sh is nonsense.

Checking is the only reason that hashes are provided.

you might have another known-good source of the hash.

You meant a binary blob in your distro's repository, so one that was checked, tested, approved and verified with a hash. Which is wildly different than downloading and running random binaries or scripts for that matter off the internet.

No, it's hardly random, it's an official binary provided the Rust project from an official domain managed by the Rust project. If you don't trust it, then you shouldn't trust the Rust source code either.

In this case, the Google internal course explicitly does not trust that random shell script, even if it came from rust-lang.org, while their internal apt repository is trusted. See https://news.ycombinator.com/item?id=34092187

When I'm installing package from the repository, it's signed with GPG. Hopefully in a more secure place than WWW server. May be even at offline server with HSM (one can hope!). When I'm running code downloaded from HTTPS, all it takes is compromising this WWW server (or AWS Cloufront for this particular sh.rustup.rs example). HTTPS adds additional attack surface.

piping to the shell might be somewhere in the middle but node's npx is just asking for trouble. You type `npx cmd` and it downloads cmd. Which means any typo could be death

This is because people are tired of figuring out seventeen (hundred) different package managers that may or may not work and that may or may not accept your package into their repo?

To be honest, the course suggests using apt since that's an easy security-approved way to install things on our computers (see https://en.wikipedia.org/wiki/GLinux).

I'll be happy to update it to suggest using rustup like "normal". Could you make a PR for that?

Actually, there is already an issue for this: https://github.com/google/comprehensive-rust/issues/19 and I hope someone will fix it soon :-)

Are you sure you're replying to the correct comment?

Sorry, you're right :-) I meant to comment further up where people asked if we could reference rustup.rs in the installation instructions.

https://news.ycombinator.com/item?id=33380755

Apt gives you the version of Rust that was packaged for your distro, so you're not keeping up with the latest releases. It's typically configured to reuse the system install of LLVM, missing some Rust-specific patches that are in the process of flowing upstream. And it references distro-packaged crates by default, meaning that again you're not getting the latest published versions.

They're using Rust in the android system: https://security.googleblog.com/2022/12/memory-safe-language...

I sit next to a guy in Mountain View that works full time just on teaching people Rust and integrating Rust into Android. There’s a whole team dedicated to getting Android developers writing Rust.

The difference in installation procedure is probably a security measure. Piping curl to bash is a bad move and it’s the Android security department that’s pushing Rust in Android. Plus, internally, Google has well maintained aptitude repositories with projects built from HEAD. It’s nice installing something like lldb from the command line and the internal Python interpreter is the latest version. And you know all of your coworkers are running that version, too.

> Is this “just” a 20% project or is this more significant (like Android one day supporting Rust to develop apps)?

It's very unlikely you'll ever see Android supporting apps written in 100% Rust (just like it doesn't support apps written in 100% C++/C) - the APIs and UI toolkit are exposed and written in Java and you'll need to bridge either way.

Supporting Rust as a native code language to augment existing support for C/C++ via NDK is much more likely.

They mention rustup on the 3rd slide.

Reply on news.ycombinator.com