3 ms·

Rust's crates.io malicious typosquatting crate "rustdecimal" security advisory

35 points by Aissen 4y ago

mooman219 4y ago
I know the crates.io maintainers have stood their ground on not namespacing crates.io (as compared to Maven or NPM), but it really feels like a sunk cost to keep going with the global namespace. It wouldn't necessarily have resolved this situation, but they would have to at least typosquat both a user and crate identifier. It feels like too many crates have to squat their own pseudo-namespace, and all bets are off as soon as people start making middleware on top of a crate.
- Xylakant 4y ago
  > It wouldn't necessarily have resolved this situation, but they would have to at least typosquat both a user and crate identifier. They’d need to typosquat the namespace identifier and then could use the same crate (and could easily do it for all crates from a namespace) - as a defense against typosquatting, namespacing seems kind of useless. A better defense would be to calculate the levenshtein distance a new crate has to existing crates and notify a human to make a decision about it - but that would (a) be computationally expensive and (b) require a human in the loop, which does not work well with a volunteer team such as the crates.io team. Your best defense is making a (partial) mirror of crates.io and only add crates after a review that satisfies your security requirements.
kramerger 4y ago
I feel the Rust situation is - despite its security focus - much worse than python & javascript. The standard library lacks a few things you find built-in in most other languages hence you have to use external crates. At the same time, the language is new so there are sometimes no "obvious" crates to select and you simply have to wing it.
justinsaccount 4y ago
> An analysis of the binary payload was not possible, as the download URL didn't work anymore when the analysis was performed. And what was the url? People that do network monitoring could look for the outbound dns/http requests to determine if any host on their network had the malicious crate. A system might even still be infected and trying to download the payload.

35 points by Aissen 4y ago

I know the crates.io maintainers have stood their ground on not namespacing crates.io (as compared to Maven or NPM), but it really feels like a sunk cost to keep going with the global namespace. It wouldn't necessarily have resolved this situation, but they would have to at least typosquat both a user and crate identifier. It feels like too many crates have to squat their own pseudo-namespace, and all bets are off as soon as people start making middleware on top of a crate.

Xylakant 4y ago
> It wouldn't necessarily have resolved this situation, but they would have to at least typosquat both a user and crate identifier. They’d need to typosquat the namespace identifier and then could use the same crate (and could easily do it for all crates from a namespace) - as a defense against typosquatting, namespacing seems kind of useless. A better defense would be to calculate the levenshtein distance a new crate has to existing crates and notify a human to make a decision about it - but that would (a) be computationally expensive and (b) require a human in the loop, which does not work well with a volunteer team such as the crates.io team. Your best defense is making a (partial) mirror of crates.io and only add crates after a review that satisfies your security requirements.

kramerger 4y ago

I feel the Rust situation is - despite its security focus - much worse than python & javascript. The standard library lacks a few things you find built-in in most other languages hence you have to use external crates. At the same time, the language is new so there are sometimes no "obvious" crates to select and you simply have to wing it.

justinsaccount 4y ago

> An analysis of the binary payload was not possible, as the download URL didn't work anymore when the analysis was performed. And what was the url? People that do network monitoring could look for the outbound dns/http requests to determine if any host on their network had the malicious crate. A system might even still be infected and trying to download the payload.