Live data from Hacker News

Typosquatting programming language package managers

incolumitas.com

41–50 of 148 posts

Re: Typosquatting programming language package managers

#41
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.

Banks generally solve the issue with simple classic checksumming methods that guarantee that any number with a typo or swapped neighbouring characters will always result in an invalid number. That doesn't work with arbitrary names because they are, well, arbitrary.

Why not? Central repositories could require that all names are within a certain Levenshtein distance of one another.

This could get mildly annoying every once in a while when there are legitimate non-clashing names. A better metric/typo recognition technique is probably possible. Or else some manual process for requesting exceptions (maybe with a tiny fee to help fund the overall project) would also address this problem.

EDIT: Just downloaded and read the thesis abstract. The author actually suggests the first idea: "The analytical part generates ideas for countermeasures that allow repository maintainers or users to detect typosquatting attacks in the future. For this purpose potential typosquatting candidates could be generated for each legitimate package name with the help of the Levenshtein distance algorithms or Bayesian networks. Another option that can be considered is the Metaphone algorithm."

Re: Typosquatting programming language package managers

#42
post #35
post #6

Earlier quoted context omitted.

There is a gem called bundle which doesn't do anything but preventing a typosquat https://rubygems.org/gems/bundle Total downloads 1,800,600 Source (empty) at https://github.com/will/bundle and interesting README. https://rubygems.org/gems/bundler Total downloads 92,116,090 It's almost the 2%.

I think the authors here missed an opportunity for even more effective squatting like that: cases where the name you import, name you type at the command line, or name you commonly call the package by is different from the name in the repository. In Python, "pytables" (should be "tables") and "skimage" (should be "scikit-image") come to mind.

Yeah. I think it's becoming a reflex for programmers when they get an import error like:

    Error: Cannot find module 'x'
to quickly type:

    npm install x

Re: Typosquatting programming language package managers

#43
> In the thesis itself, several powerful methods to defend against typo squatting attacks are discussed. Therefore they are not included in this blog post.

http://incolumitas.com/data/thesis.pdf section 5 "Practical implications". Just wanted to point out that in case you skipped it it's worth a read, some interesting proposals there that are worth discussing with package manager maintainers.

I particularly like the preemptive approach of auto-blacklisting common typos by simply monitoring the number of times a specific unexisting package is requested over time (5.10). So if a lot of people regularly attempt to install the unexisting package "reqeusts", it could signal that it's a common typo and should be blacklisted to prevent malicious use in the future. False positives could always be sorted out manually by communicating with the package manager maintainers.

Re: Typosquatting programming language package managers

#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 few months, however I think this is a good argument for never having it be fully automatic. Having a human sanity check submissions isn't a terrible idea if we can keep the workload down.

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.

[0] https://packagecontrol.io

Re: Typosquatting programming language package managers

#45
post #20

This seems like pretty unethical research to me. Also, doesn't point out that the bigger threat is that this is wormable.

There was no actual intrusion, so this feels like fair game to me. Especially since mitigating a very possible attack vector is a direct result of running experiment. Still, hopefully the researchers got an IRB to sign off on the experiment setup...

Re: Typosquatting programming language package managers

#47
post #25

Did anyone else find it surprising the the number of total requests (45334) is so much higher than the number of unique total requests (17289)? It is more than twice the number of unique requests! Possible explainations: * Perhaps many of those are automated build systems, which would also explain the high number of systems with admin access (for example, if you use travis without docker, every build runs in a clean…

Automated testing, continuous integration/delivery, et cetera download and install packages pretty often. If the type is made in the requirements.txt or package.json or what have you, the error can be repeated very often up to and including production.

Re: Typosquatting programming language package managers

#48
post #25

Did anyone else find it surprising the the number of total requests (45334) is so much higher than the number of unique total requests (17289)? It is more than twice the number of unique requests! Possible explainations: * Perhaps many of those are automated build systems, which would also explain the high number of systems with admin access (for example, if you use travis without docker, every build runs in a clean…

I think he forgot to define a baseline (could be wrong, I didn't read the paper). He should have generated a few packages with a completely innocent name (and maybe some packages with just a GUID as a name) to see how much downloads / installs they get too.

Re: Typosquatting programming language package managers

#49
post #39

Earlier quoted context omitted.

I think we will have to rely on crypto hash in some form. Similar to download checksum. It won't be convenient, but it will be safe(r).

That doesn't really save you from typos

I was thinking something along the line of a mandatory hash/checksum along with the name of the software you are trying to install from a package manager. It does not have to be very long, just enough to avoid common collisions.

Re: Typosquatting programming language package managers

#50
post #25

Did anyone else find it surprising the the number of total requests (45334) is so much higher than the number of unique total requests (17289)? It is more than twice the number of unique requests! Possible explainations: * Perhaps many of those are automated build systems, which would also explain the high number of systems with admin access (for example, if you use travis without docker, every build runs in a clean…

In the case of python (not sure about the other package managers) if a valid package requires the hacked package, each project that requires that valid package will download and install the hacked package separately if you're using virtual environments. Also if you're using docker you reinstall everything when your requirements file changes.
Post reply on HN