The malicious "rustdecimal" crate

Posted May 11, 2022 20:28 UTC (Wed) by wtarreau (subscriber, #51152)
In reply to: The malicious "rustdecimal" crate by epa
Parent article: The malicious "rustdecimal" crate

It just illustrates the problems with distributed development with excessive trust of unknown dependencies. When you think about it, a bit of googling or stackoverflow sends you to the wrong lib, you add a dependency to it and that's all you have to do, nobody checked any update, there's no intermediary distro maintainer involved to have a review before it lands in the OS. There's the same problem with other languages like perl, python, nodejs and so on where everyone finds it totally normal to automatically download half of the world's creativity and use it as a building block for something that will eventually reach production.

I should serve as an illustration about "what if the author was really badly intented". Because clearly it looks like an experiment that should serve as a warning against such bad practices. Similarly if I had time to waste I'd create a stupid project that randomly does nasty things to those who install it via the documented "curl | sudo" procedure.

The malicious "rustdecimal" crate

Posted May 12, 2022 4:04 UTC (Thu) by developer122 (guest, #152928) [Link] (8 responses)

Curl Sudo isn't the level of problem people make it out to be.

If HTTPS is enforced and you got your download URL from a trusted source, then it's no different from installing through a package manager. It's merely a question of whether you trust the person owning that website and providing the install script as much as you trust canonical/debian/etc.

It's a janky way to install things, but it isn't an insecure one.

The malicious "rustdecimal" crate

Posted May 12, 2022 4:42 UTC (Thu) by pabs (subscriber, #43278) [Link]

You also have to trust their hoster, while you don't have to trust the hoster with a traditional package manager.

The malicious "rustdecimal" crate

Posted May 12, 2022 9:21 UTC (Thu) by cortana (subscriber, #24596) [Link]

No, the necessary level of assurance can only be achieved by using a https URL and checking the signature of the downloaded data throughout the supply chain.

The malicious "rustdecimal" crate

Posted May 12, 2022 13:01 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

Ah ah, the trusted source is almost always https://github.com/something and it always comes with a valid certificate without having to make any effort :-)

The malicious "rustdecimal" crate

Posted May 12, 2022 17:09 UTC (Thu) by ballombe (subscriber, #9523) [Link] (4 responses)

There are instance where domain name renewal was allowed to lapse and the new owner replaced the software by a trojaned one.
HTTPS and domain name ownership are insufficient.

The malicious "rustdecimal" crate

Posted May 12, 2022 22:01 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (3 responses)

> There are instance where domain name renewal was allowed to lapse and the new owner replaced the software by a trojaned one.

In terms of installation of software from new sources (as opposed to updates to existing software or centralized repositories managed by distros) the validation instructions, e.g. a GPG public key or signature file hosted on the same domain, are just as vulnerable to this sort of attack as the script itself. If you don't want to be reliant on control of the domain name you need some out-of-band system to validate your sources, such as a PGP Web of Trust, but these systems have not really caught on as a practical general solution thus far. Identifying the source by its public key, e.g. using IPNS, or Tor .onion domains, would be one alternative; then the root of trust is pushed back to whoever directed you to that source.

A more immediate problem with `curl | bash` is ensuring that the script is safe with respect to truncation; there is no buffering, so if the connection is interrupted `curl` just reports EOF and `bash` will attempt to run whatever was received for the interrupted line as if it were a complete command.

The malicious "rustdecimal" crate

Posted May 13, 2022 9:31 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

> A more immediate problem with `curl | bash` is ensuring that the script is safe with respect to truncation; there is no buffering, so if the connection is interrupted `curl` just reports EOF and `bash` will attempt to run whatever was received for the interrupted line as if it were a complete command.

Exactly! I'm pleased to read this because I feel like I'm constantly blowing in the wind when I say this, and even people do not believe my examples :-/

The malicious "rustdecimal" crate

Posted Jun 12, 2022 6:54 UTC (Sun) by marcH (subscriber, #57642) [Link] (1 responses)

In general, "cmdA | cmdB" is not safe without "set -o pipefail".

Safety discussions are a bit ridiculous the moment you use a language that ignores errors by default. We love high level discussions about memory safety and borrow checkers but in the real world the problems often start much more mundane: many C programs discard errors and even when they don't the error handling code has never been tested.

The malicious "rustdecimal" crate

Posted Jun 12, 2022 21:38 UTC (Sun) by nybble41 (subscriber, #55106) [Link]

> In general, "cmdA | cmdB" is not safe without "set -o pipefail".

In the case of `curl | bash` the command isn't safe even *with* `set -o pipefail`. The problem isn't the exit status of the pipeline (which would typically be ignored in any case) but rather the fact that it runs the script *as it's being downloaded*, without ensuring that the entire script is available before the first command is executed, and even worse that the shell will attempt to execute the last line downloaded even it was truncated.