Glad to hear bower is stated to be safe in this regard :)
Typosquatting programming language package managers
91–100 of 148 posts
Re: Typosquatting programming language package managers
#92This seems like pretty unethical research to me. Also, doesn't point out that the bigger threat is that this is wormable.
Yea, this would never get past my university's ethics department. I'm actually surprised he was allowed to do this. Maybe it's partially due to the fact our ethics department is also worried about liability.
Re: Typosquatting programming language package managers
#93So last week my client discovered there's a gem named bunlder... sigh
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%.
My gem has a good downlaod/loc ratio.
Re: Typosquatting programming language package managers
#94Earlier quoted context omitted.
This is obviously not true. If `serde` resided at `erickt/serde` (as the counterproposal for Rust would've had it), I could create `erict/serde` or `erick-t/serde` or any other variations of erickt's handle. The only way this is 'solved' is if some third party authority hands out top level names and refuses to register names that are similar to other names for some definition of similar. The number of levels between…
Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.
That reduces the likelihood of success (erick-t/srede requires 2 typos) but doesn't eliminate the possibility.
Re: Typosquatting programming language package managers
#95This seems like pretty unethical research to me. Also, doesn't point out that the bigger threat is that this is wormable.
Perhaps this could have been made cleaner by relying on the package manager for download counts only, and then demonstrating the code execution scenario on research machines only. If you wanted to avoid actually downloading anything to the user's machine (after all, they expect a 404 in this case, not a package even be it a harmless one) you'd perhaps need the cooperation of the repo admins to a greater extent.
Anyway, this is all part of why I always try to build inside a container, or at least in a virtualenv where I don't need to sudo the install.
Re: Typosquatting programming language package managers
#96This only seems to be an issue for languages where packages reside in a global namespace, like Python, Rust etc. I think most languages these days are a bit smarter and avoid this beginner mistake (for various reasons).
This is obviously not true. If `serde` resided at `erickt/serde` (as the counterproposal for Rust would've had it), I could create `erict/serde` or `erick-t/serde` or any other variations of erickt's handle. The only way this is 'solved' is if some third party authority hands out top level names and refuses to register names that are similar to other names for some definition of similar. The number of levels between…
You are obviously wrong.
While attacking a single package would be possible, covering any interesting amount of "typo"-space would require registering huge amounts of namespaces.
If package manager developers are smart, the allocation of namespaces is also handled externally and associated with some cost (e. g. domain names).
Therefore these kinds of attacks become impractical.
Re: Typosquatting programming language package managers
#97Earlier quoted context omitted.
But if ABD and ABC are both package names in the system, then in order to present that warning we have to do some sort of resolution process to determine whether one is typosquatting. Now that there's a strategy for finding fakers: 1) You have an attacker-defender arms race. The attacker will always be one step ahead of the defender. 2) You have the extra burden of keeping up in this race, otherwise your security fea…
I feel like "pick the more popular package" is a good enough solution in this case.
Cool. Attacker-defender race is on!
As attacker, my next strategy is create a bunch of agents (Your move, defender ;)
But seriously, my point has less to do with the particular tactics of the adversaries and more to do with how the proposed strategy of automatically detecting potential typos invites gaming.
Re: Typosquatting programming language package managers
#98Instead 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.
"You requested package ABD, but we think you might mean package ABC. Enter 'yes' to continue or anything else to start over."
That'll be fun to automate around in puppet or ansible.
Re: Typosquatting programming language package managers
#99The homebrew model where packages and changes to packages are reviewed takes care of this problem quite nicely.
Re: Typosquatting programming language package managers
#100When you think about it, how different is the destructive potential of an npm/pip install from curl | bash that (some) people tend to froth at the mouth about? It's pretty mind blowing how big of a blindspot package installers are. I guess running everything inside a e.g. Docker container/VM would be a partial interim solution for the paranoid?
For me they're very similar. I actually did a talk last year for OWASP AppsecEU where I started with the curl|bash bit and pointed out where rubygems/npm etc aren't really a lot better in some ways