Have you run a cross-language comparison?

[workingjubilee]

I am curious if you have evaluated your requirements against XCode, Visual Studio, Autotools (best known as "that thing that runs when you clone a repo and call ./configure in it"), Makefiles, CMake, Meson, Python's various packaging systems of Python (which can involve building native code, thus transitively include the previous systems), Node.js NPM, RubyGems and Bundler, Java's Gradle or Maven, etc.?

For instance, are you familiar with C's #embed? You may wish to file a report to clang.

[Noratrieb]

notably, NPM has post-install scripts, which are exactly as bad as a Rust build.rs script

[bf]

Hi @workingjubilee, thanks for your comment!

Many languages have such same problems. Node's NPM is a very good example because it made all the mistakes before, so rust should've learned from it. But why can't rust learn from it?

Supply chain attacks do and will happen; and nation states are actively searching for them.
Either it is someone stealing your crates.io tokens the traditional way or a maintainer going rogue (e.g. being forced by the dictatorship they live in).

Rust pushes everyone to use centralized service of crates.io, but they're not even trying to simulate a defense-in-depth approach for handling malicious third-party modules. Users are not warned if include_str() accesses the home folder and steals ssh keys. You can lose your whole digital existence by running cargo doc on unknown files.

There is no technical reason why basic security controls and notifications can't be implemented.

[bjorn3]

A lot of crates depend on build scripts or proc macros for whatever reason. Sandboxing those is non-trivial as different OSes have different interfaces to sandbox things, build scripts may have a legitimate reason to access files outside of the source directory (for example invoking a system installation of a C compiler, which in turn requires accessing system libraries) We do want to add support for this in the future, but it is a non-trivial amount of work both to implement and to do so in a backwards compatible way (which at least initially requires the sandbox to be opt-in). Absent sandboxing of build scripts and proc macros, any attempt at making rustc enforce a sandbox for the code it compiles is nothing but security theater and only gives a false sense of security.

[bf]

The crates rely on it because it's provided out of the box. Sandboxing should be implemented where possible and users be warned where it is not possible. Many of the hardcore features are used by large projects and should be disabled by default for 99% of rust users. Debugging visualizer? Enable it when needed. Code execution in rustdoc? Enable when needed. Third party depencency with maintainer in shanghai? Let use decide before it can read your whole disk and upload it to Alibaba cloud.

non-trivial amount of work

The work has already been done, rust just needs to use it. Most work is interfacing with humans who somehow depend on not seeing the issue.

security theatre

Rust is offering both crates.io and the programming language, and then saying "trust me bro" when asked about security.

Security theatre is when idiots like me think that rust is a security-minded project and focused on quality, because they gobble up the nice marketing material, but the fundamentals are really bad.

[Noratrieb]

If the work has been done, please submit it :). I don't think the work has been done. Requirements:

• be reasonably secure against malicious crates at compile time
• don't break existing code
• don't require opt in all over the place
• handle all the cases people want

Bonus points for not luring people into a false sense of security for then running binaries.

But even then, we can't 100% defend against attacks. rustc w
depends on LLVM, and LLVM considers all inputs to be trusted. They have to, as it's written in C++ and they really don't want to treat every bit of memory unsafety as a vulnerability.

[Noratrieb]

I promise people are interested in sandboxing proc macros and build scripts. If you want to improve that space, improvements are welcome, but what we need are not reports (we know it very well already), we need people to put in the work of making it happen. If you don't believe me that it's hard, you can figure it out yourself :)

(and the reason that your reports have been met with resistance is not because we don't care about the problem at all, it's just that they are pretty confused about the thread model imo. even if we extend the threat model to simple supply chain attacks (which it currently isn't at all because of proc macros and build scripts), they're not really a concern).

[bf]

@Noratrieb I appreciate your openness and the kind words!

Unfortunately I'm not getting paid for this, and it takes a lot of energy to discuss with people working for big corporations. I feel rust project is actively tarpitting security initiatives also from other people, due to whatever reasons.

be reasonably secure against malicious crates at compile time

The main focus of my post was to show that it's not a compile time problem. With rust, it is a formatting time problem (rustfmt). And a documentation generation problem (rustdoc). Somehow in rust everything is compiling - as you said the scope of macros is a big problem here. You can run source code, macros, doctests, and many other things.

don't require opt in all over the place

Microsoft is a big sponsor of the project, maybe ask them about opting in to sane defaults :-P Didn't chrome just force all websites to use https:// instead of http://? Why do rust power users who use the programming language as their main source of income not adapt to some config changes and more secure defaults? Can't I expect someone who wants to use rust-gdb maybe set the flag unsafe_parse_debugger_stuff_from_dependencies=true in their cargo.toml?

people are interested

Yes, but all tickets related to this are open after many years. And whole countries are not interested into making rust ecosystem more secure, because it makes it harder to execute supply chain attacks. When I use rust from within china, can I connect to the "official" crates.io server or is there a version of crates.io within the great firewall?

met with resistance

I'm used to that, no worries - that's what I get for asking stupid and naive questions :-)

confused about the thread model

My threat model is open source projects being hindered by paid malicious actors. There's a reason why openoffice is still shit after all these years. Maybe it's time for a rust-hardened.

[theemathas]

Did you know that pip install can execute arbitrary code?

Solving this issue is hard.

[Noratrieb]

Unfortunately I'm not getting paid for this, and it takes a lot of energy to discuss with people working for big corporations.

as someone who does all Rust in my free time, I understand.

The main focus of my post was to show that it's not a compile time problem

That's fair, I just grouped everything that's not running into compiling, but there may be value in treating then differently.

Can't I expect someone who wants to use rust-gdb maybe set the flag unsafe_parse_debugger_stuff_from_dependencies=true in their cargo.toml?

No, I think that would be a bad experience and confusing. We want debugging Rust to be as easy as possible, and such flags are also not good for sefueity because people will often just enable them. I think a solution here ties into build sandboxing, where you restrict the directory of source files to the source directory. But this is hard, just like everything else about build sandboxing.

My threat model is open source projects being hindered by paid malicious actor

Accusing us of being hindered by (or even being!) paid malicious actors is really not nice and will certainly not help your points. I don't think anyone will be interested in talking with you about Rusts security if that's what you're talking about.

[bf]

@theemathas yes, but who will solve it if not rust? I drank the coolaid and expected rust to at least address these issues.

In 2024 we shouldn't hand-wave away supply chain attacks or nation state actors. And open source projects are especially vulnerable to their negative influence.

How can a contributor to rust from a non-free country resist the state police who show up at their house? What would be the objective they are given? "This stupid programming language stole our buffer overflows, at least keep the supply chain attacks available".

Same with the bs platform argument. If Linux can do proper containers and there is docker allover the rust repository, then it's a problem for Windows developers to fix their AppGuard and offer adequate APIs. Some years ago if chrome added a new feature like tab sandboxing, both firefox and internet explorer were quick to implement it as well.

@Noratrieb I appreciate you taking the the time to respond, and I don't want to insult you or anyone else personally. I'm trying my best to argue about the situation. I know there are many unpaid individual contributors and try I respect their work.

[Noratrieb]

You we're very much failing at your attempt to not insult anyone with that one.

Look, we all want security, but security is hard. You can't just make cargo stick the build script into a docker container and call it a day. That would break everything.
You need sandboxing while keeping all the stuff working and making most cases things work and still have opt outs but don't let that compromise security and be transparent about communication and accept this won't be a 100% solution etc etc.

I don't have anything else to say. If you don't understand that this is hard, then you will get an incorrect impression. I encourage you to figure out why this is hard yourself by implementing it, maybe it will turn out to be easy and you'd have been right all along.

[bf]

For reference, this is usually a whole document.

@T-Dark0 you didnt by any chance have a look at https://github.com/bf/rust-security-problems/blob/main/README.md, did you?

The thing you cannot do is claim that there is a problem when you do not have a description of what a problem even is

I have no words, sorry. The audacity to write such a long essay and totally missing the point.

You we're very much failing at your attempt to not insult anyone with that one.

@Noratrieb I get swarmed by people with anonymous accounts and bad arguments.

[bjorn3]

Fun fact: Apparently a security-conscious member of the rust project implemented a security control to prevent macros from reading arbitrary environment variables, but this security control is useless as rustdoc can directly read the /prov/self/environ file.

This is actually not for security reasons. In fact when those env vars are set, it has absolutely no effect whatsoever. Instead it is to get a better error message when accidentally using env!() instead of std::env::var() in proc macros.

[bf]

You have not contributed to the discussion.

@shadow-marker it seems you created this anonymous github account simply to troll in this thread.
It's getting ridiculous, go back to discord!

[workingjubilee]

Same with the bs platform argument. If Linux can do proper containers and there is docker allover the rust repository, then it's a problem for Windows developers to fix their AppGuard and offer adequate APIs. Some years ago if chrome added a new feature like tab sandboxing, both firefox and internet explorer were quick to implement it as well.

Containers are not a meaningful security boundary on their own, and we do not use them for that purpose.

I do not understand the rest of what you are saying, because on Windows, Docker runs Linux containers inside a hypervisor because they're... well, Linux containers. The hypervisor boundary does provide some security. On Linux, it runs them against the same kernel, and thus requires additional measures to secure the program.

The operating systems have all the means to securely run programs already. They mostly do not because it would break existing software that depends on ambient authority working. However, Android and iOS both enforced stricter security policies from the start, so they do not have as much of an issue. Software on them has a permissions-centric ACL that better fits the model of your expectations.

Of course, the Rust compiler would still need permission to read and write to files, so you may or may not find their design for permissions fine-grained enough.

[workingjubilee]

In other words:

Many languages have such same problems. Node's NPM is a very good example because it made all the mistakes before, so rust should've learned from it. But why can't rust learn from it?

Because "in the Rust toolchain" is not necessarily the best place to solve the problem. The operating system is. Rust is useless at its goals if it is not adopted. And most current designs for building software on operating systems, often maintained by very hidebound traditionalists, require the ability to work with environmental inputs. So the choices are "compromise and be usable in actual programs, which makes the programs that execute more secure", or "be some useless academic tool that no one runs and Benjamin Flesch never heard of".

Rust chose the route where you hear about it instead of it quietly dying only a few years in.

[bf]

@workingjubilee thanks for your explanations. I appreciate you taking the time for discussion.

My viewpoint is that developers and the orgs they work for are prime target for attackers. Rust is a target-rich environment in that sense. Supply chain attacks are one of easiest attack vectors especially for state-level actors who can MITM centralized module repositories by design.

My expectation when first using rust was that the robustness / safety principles would be religiously followed in design and development. While rust is excellent on the level of the language, the moment macros and crates.io modules come in it all goes out of the window. This is where my disappointment comes from.

Due to my experience in terms of security risk assessments, I noticed what many people have noticed before me: The emperor has no clothes, because the whole thing is only as secure as it's weakest parts.

IMHO there should be as many guardrails (safe defaults) and notifications to the user as possible. Module foobar-async from crates.io adds python script to rust-gdb? Security Warning. Module sqlite includes files from my home directory? Block it, let user decide.

Rust designers thought of an unsafe {} syntax when doing risky programming, but then a different thinking was used when handling crates.io modules.

In issues raised like rust-lang/rust#133838 (comment) where macros are parsed from dead code they conclude with:

rustdoc/rustc necessarily does total macro-expansion before it can do name resolution and then everything else

and

You're not wrong that a lot of clever tricks can be done here with sufficient work and a sufficiently rearchitected compiler to handle some such cases. It's just really not worth it, macros are defined to always expand and there's not really any actual problem that causes.

Which confirms that it's insecure by design - a full rearchitecture is needed. While rust was a massive step forward from the status quo at the time, the macro and crates.io stuff taped on top of it needs to be refactored.

Rust project is a perfect storm between corporate types and state-sponsored actors who have an incentive to delay any kind of security improvements with arguments like:

"Solution needs to be 100%":
Derailing discussion & basically prevents any change because there will never be optimal solution. They try to make you think about all edge cases for all rust users, while any other large OSS project showcases that strong decisions are needed to achieve desired results, and there's always a downside to consider.

"Trust me bro (our NPM is safe)":
Rust seems to do scanning at level of crates.io but not sure if the people who do it even have an incentive to make bad PR about the project that pays them. If a supply chain attack was discovered, do you realistically think that crates.io would report about it? Basic principle of security is trust, but verify.

"My government handlers want to keep their supply chain attack vector untouched":
We must understand that when someone is from a non-free country they and their family will be harmed if they don't do what is asked from them. If you are a software engineer in a project like rust this includes delaying security improvements or getting access to crates.io keys so a MITM supply chain attack can be performed on a small subset of users.

A big indicator for malicious state-sponsored actors is that once security hard facts are pointed out, the anonymous accounts appear and try to smear and derail the discussion - feels like intimidation is all they know. They can't provide constructive input but they will give many reasons why it is bad to improve security.

There must've been many idealistic people working on the rust project, and I assume you are one of them. But we shouldn't bs ourselves. If you can't put your real name next to your github account and you're exhibiting anti-security behavior, there's always a reason why you are hiding.

If these anonymous accounts choose to stay anonymous because they're the best hackers in the world then they would understand the security issues which have been raised many times and actually think about solutions.

From the first interaction with rust representatives onwards it was a discussion about political decisions how security should be handled. It's fine for rust project to do that and for participating individuals to be defensive for sake of their careers - but for outside observers it's apparent that rust project follows different interests than software quality.

Sorry for the long essay again. I wish you all the best.

[bf]

I still don't get why you are insisting that reading arbitrary files and only embedding them in the executable is harmful in any way.

Sorry at this point it's like arguing with a flat earther. Due to fact that you are anonymous account and you repeatedly show up derailing the discussion with the biggest mental gymnastics, I have to assume the worst about your intentions.

If you are worried about ..
.. no benefit to a cargo provided sandbox ..

As I pointed out above, this is textbook example of "if it doesnt work 100% then not worth to do it". Classic detraction. Defense in depth is not a concept I have to defend here.

You are aware that gdb uses several components that are so vulnerable

Whataboutism

[theemathas]

you are anonymous account

"Bjorn" is a reasonably common name that people have. https://en.wikipedia.org/wiki/Bjorn

This Bjorn in particular is currently the 9th most prolific contributor to rust, when measured by the number of commits. https://github.com/rust-lang/rust/graphs/contributors

[bf]

What's your point? That someone with big enough incentive can build up a fake persona in order to reach an influential role in an open source project? Did you actually read the comments he wrote the last few days?

This Bjorn in particular is currently the 9th most prolific contributor to rust

This scares me.

[workingjubilee]

Sorry. At first I thought you might be like, reachable or something if I tried to explain things about which you were clearly not an expert. And I'm sorry this is apparently causing you grief? But your responses are making it pretty clear I should not have tried.

You're claiming that people who have very real public identities are insufficiently identifiable to interact with you. They do have known identities, but you seem to demand a name and face, I guess, or else they're anonymous? It's hard to tell exactly what your conditions are. At best, I must assume you are simply totally ignorant that e.g. even in FOSS, women with accounts where their gender is easily identified are treated worse on average. I would hope you are not deliberately in favor of people making themselves more subject to sexism in general, as a condition of interacting with you?

I mean, bjorn3's a dude, last I checked, but I'm generally pretty firm on "what's good for the goose is good for the gander", especially vis-a-vis social norms designed to protect people from needless discrimination.

And that's to say nothing of the constant gross insinuation that a group that includes many volunteers who are donating their free time out of the kindness of their heart are either fucking corpo stooges or spies and saboteurs? Like, really?

Anyway, seeya.