Source
mgattozzi•

They used crates.io for the attack? That's nuts and really clever.

40
crusoe•

They used it as a side communication channel to configure the exploit.

7
dbaupprust•

Thanks for running this, and awesome work to both candidates. I like the trait/as trick (and it seems like something clippy could flag, if not the language itself improving), and using crates.io's JSON to feed in secret information is... amazing.

20
KasMA1990•

Does anyone know if any of these attacks are resulting in concrete actions to avoid them happening in real life? Maybe introducing new lints?

9
kibwen•

For the entry that exploits the borrow checker bug, that attack will be obviated when the two-phase borrows RFC lands, hopefully later this year. For the entry that uses crates.io as a remote control, I believe some change to Cargo's behavior has been introduced to make it less reliable, but I'm not sure what a bulletproof fix would even look like. For the entry that shadowed standard macros, I think macros 2.0 will help address that by allowing macros to use namespaces like any other identifier. And for the trait shadowing entry, the attack seems contrived enough that I'm not sure that any official action needs to be taken, though I wouldn't be opposed to extending clippy to catch it.

5
KasMA1990•

Cool, thanks! :)

1
fgilcherrust-community · rustfest•

The underhandedness contest isn't about attacks per se, but about hiding something nefarious in (presumably) trustable code. Indeed, most of the approaches here work by using absolutely usual behavior in an unexpected combination.

Take, for example, the crates.io sidechannel: it exploits the fact that many build their software on the same machine they run it on. It then crafts it's own data format towards the crates registry format. There's not much we can do against that, except teaching people that one of the cool things about Rust is that running application doesn't need the package manager around (in contrast to, say, Ruby). All of the parts are sound there, except the user application, which was specifically crafted to be exploitable and uses a sound piece of software to sneak into. On application platforms like Heroku, which have separate build and deployment stages, this wouldn't work.

The borrow issue will totally be fixed.

4
KasMA1990•

Calling it "attacks" was probably wrong of me; you're right that this is not attacks, but some of it is still just bad code, that at the very least can be footguns. Like the macro export issue for example; is there something we can do about that?

3
crusoe•

Path.join throws away preceding path if path being sdded is absolute? Seems buggy to me....

5
birkenfeldclippy · rust•

Only if you think of paths as strings.

If you think of paths as paths (works even literally, as a series of commands "start from root, go left, go right, .."), it makes a lot of sense.

8
Guvante•

That is the intended behavior because it designed to work like a relative directory. You can have a configuration flag that sets where to store a file and allow your users to avoid having to play .. games to go up. It isn't made to take an untrusted string.

7
matthieum•

This still seems very bizarre to me, to be honest.

Apparently it's a thing, but I would have preferred a "warning" here (maybe a disjoint return type), because it seems quite unexpected.

1
Guvante•

Honestly using a user supplied string in a path is just asking to get owned in this way in general. Don't try and black list just white list.

2
epage•

I know Python's pathlib is the same way.

1