Live data from Hacker News

Typosquatting programming language package managers

incolumitas.com

71–80 of 148 posts

Re: Typosquatting programming language package managers

#71

Earlier quoted context omitted.

Or just refer to packages by 2 names. Maintainer/PackageName It solves so many problems, this included.

One imagines that "Maintainer" could be typoed as e.g. "Maintaner" just as easily as "PackageName" could be "PackagName".

But then the attacker would need to register a ton of packages that match other popular packages under their namespace which can set off some alarms. (I guess "solve" was a bit too strong of a word to use there...)

There could also be some other cool tricks you could apply (This is the first time you are installing a package from "Maintaner", would you like to continue?)

Re: Typosquatting programming language package managers

#72
post #44

We've gotten flack from package developers submitting new packages to Package Control [0] because all additions to the default channel are hand reviewed. Part of this process is to prevent accidentally close package names, to try and encourage collaboration and to encourage developers to actually explain what their package does and how to use it. My hope is to be automating a large amount of the review in the next fe…

> Certainly this doesn't prevent a malicious author from posting a legitimate package and then changing the contents to be malicious, but that can be somewhat solved by turning off automatic updates.

Perhaps you could make this safer by adding an automatic check for how much the package has changed since the last version? And at least warn the user when they want to update?

Re: Typosquatting programming language package managers

#73
post #15

Earlier quoted context omitted.

Banks have a similar problem when people write cheques or set up standing orders. You have to put a name and the account number. I wonder if you could do something similar here - enter the name of the package and a code of some sort. I haven't thought this through in a lot of detail.

Or just refer to packages by 2 names. Maintainer/PackageName It solves so many problems, this included.

This is all half of a much larger problem, which is package identification. Perl 6 specced out[1] quite a bit of a future system to handle a lot of this, and I believe a lot of it is now implemented. A few things you need to consider:

- Maintainership can change over time.

- Multiple people may trade off releasing a package, but it's still the same package.

- There may be multiple repos (consider you may want to run a local company repo for non-redistributable modules).

I imagine in the end, one of the better approaches to the installation name typo problem might be to scan the code for what packages are required (utilizing as much specific information as possible), and confirming that exists as a local package that can be installed or offering to install it. Package installers should be able to take a source file or files, and install modules listed within. This won't solve all cases (dynamically determined and loaded modules may be a problem still), but it will solve quite a bit of them.

1: http://design.perl6.org/S11.html#Versioning

Re: Typosquatting programming language package managers

#74
with npm there should be at least an option which prompts for Y/N/A when package has preinstall hook.

but even this just tries to put the problem under carpet. you could still for example have requests package which just installs request package, works as expected, just sends request/response to your own server from time to time. ie. when there's http basic auth used only.

Re: Typosquatting programming language package managers

#75
post #72
post #44

We've gotten flack from package developers submitting new packages to Package Control [0] because all additions to the default channel are hand reviewed. Part of this process is to prevent accidentally close package names, to try and encourage collaboration and to encourage developers to actually explain what their package does and how to use it. My hope is to be automating a large amount of the review in the next fe…

> Certainly this doesn't prevent a malicious author from posting a legitimate package and then changing the contents to be malicious, but that can be somewhat solved by turning off automatic updates. Perhaps you could make this safer by adding an automatic check for how much the package has changed since the last version? And at least warn the user when they want to update?

I don't know how much checking for how much the package has change would help. You wouldn't need to change much to exploit - one line that downloads and executes code from somewhere would do it.

Re: Typosquatting programming language package managers

#76

Earlier quoted context omitted.

couldn't you register a typo namespace?

Yes, but then you'd need to also register a ton of packages under that namespace. That's something that can be flagged for manual review before it gets too far.

maybe I don't understand the namespaces...

but if you are targeting a package `someuser/popularpackage` can you not just register your own malicious `popularpackage` under a typo namespace like `smoeuser`?

Re: Typosquatting programming language package managers

#77
Instead of blacklisting, why not respond with a "You requested package ABD, but we think you might mean package ABC. Enter 'yes' to continue or anything else to start over."

That way authors can continue to use any name they want, and the emphasis is on letting installers know that they might be installing the wrong package.

Re: Typosquatting programming language package managers

#78
post #73

Earlier quoted context omitted.

Or just refer to packages by 2 names. Maintainer/PackageName It solves so many problems, this included.

This is all half of a much larger problem, which is package identification. Perl 6 specced out[1] quite a bit of a future system to handle a lot of this, and I believe a lot of it is now implemented. A few things you need to consider: - Maintainership can change over time. - Multiple people may trade off releasing a package, but it's still the same package. - There may be multiple repos (consider you may want to run…

Those are some good points, and I guess in my head I'm thinking of how Github does repos on their site as my "example".

Github allows transferring of repos to another "namespace" (username), and will even forward requests from the old one to the new one for a while (how long i'm not sure...)

Thinking about it a bit more that kind of "mutability" might not be the best idea in a package manager...

Still, i think the namespaces can help more than they hurt if the platform is designed with them in mind, as even "namespace-less" systems still suffer from some of those issues like wanting to rename a package or split it up into multiple smaller packages.

Re: Typosquatting programming language package managers

#79

Earlier quoted context omitted.

One imagines that "Maintainer" could be typoed as e.g. "Maintaner" just as easily as "PackageName" could be "PackagName".

But then the attacker would need to register a ton of packages that match other popular packages under their namespace which can set off some alarms. (I guess "solve" was a bit too strong of a word to use there...) There could also be some other cool tricks you could apply (This is the first time you are installing a package from "Maintaner", would you like to continue?)

An attacker would only need to register the equivalent of the package under attack. Other packages would continue to error out harmlessly as they did before.

The maintainer-level confirmation could be of slight assistance to advanced users, but it's no panacea.

Re: Typosquatting programming language package managers

#80

Earlier quoted context omitted.

Yes, but then you'd need to also register a ton of packages under that namespace. That's something that can be flagged for manual review before it gets too far.

maybe I don't understand the namespaces... but if you are targeting a package `someuser/popularpackage` can you not just register your own malicious `popularpackage` under a typo namespace like `smoeuser`?

Yes, but my thought was it gives a bit more "data" to work with on the package manager's side.

They can see someone registering popular package names under something with a similar namespace and can flag them for manual review (which can be done for namespace-less packages, but there will be much more noise), they can apply things like "This is the first time you are installing a package from 'smoeuser' would you like to continue?", or even require adding a specific namespace "out of band" depending on how paranoid it wants to be.

Post reply on HN