Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious software libraries found in PyPI posing as well known libraries

nbu.gov.sk

Post reply on HN
Print view View original

171–180 of 254 posts

Re: Malicious software libraries found in PyPI posing as well known libraries

#171

Post by kasabali »

zokier wrote: post #163
kasabali wrote: post #53

Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly. They solved the issue 2 decades ago by heavily vetting packages before accepting them into repositories. Users are allowed to add and use packages from 3rd party repositories. Maybe solution to this is creating curated repositories based on publicly open ones and using them by default (and requ…

> Yet another attack vector that doesn't exist at all in Linux distributions but invented by language package managers, sadly Not really, PPAs (and equivalents like copr or obs or aur etc etc) are mostly vulnerable to similar problems. People do want to install upstream software for various reasons, blaming language package managers for the reduced security of that is imho disingenuous.

Read my comment carefully. Though I've used terms loosely you'll see I'm actually talking about package repositories and their inclusion policies.

Re: Malicious software libraries found in PyPI posing as well known libraries

#172

Post by acdha »

raesene6 wrote: post #28
chatmasta wrote: post #12

Package managers seem to be an increasingly popular attack vector. It's only luck that none of the attacks have been particularly malicious yet. Considering how many package manager downloads go to a server in a datacenter, a widely distributed malicious package could control a botnet with extremely high throughput, or wreak havoc on any databases it comes into contact with. It's only a matter of time before somethin…

Another fun fact to consider is that with many package formats, you can execute arbitrary code at install time so if a malicious package can get into a repository, it's very likely to start compromising systems quickly. Whilst a package manager repo. compromise would be the biggest bang in terms of attack, compromising the credentials of the developers of popualar libraries would be an easier attack (and indeed is al…

I was recently very surprised to see an expensive security scanner which builds apps as the service account apparently without sandboxing. A package manager which executes code or which is exploitable would give you access to what is very likely an interesting account & data, and in at least some cases might not leave many clues behind. PyPI, etc. at least has centralization and immutable versions but who knows what's serving some random repo, tarball, etc. which might not even be a direct dependency?

Re: Malicious software libraries found in PyPI posing as well known libraries

#173

Post by acdha »

striking wrote: post #160
tekromancr wrote: post #159

Earlier quoted context omitted.

I almost never see this. Even on systems that are only running a single python project, I only ever see folks use virtualenv. The only time I ever see things installed with sudo is when the package is being installed in a docker container.

This used to be super common, though. I see it all the time in legacy apps.

Yes – to the degree that it's uncommon now that's because many people in the community spent years loudly advising against it.

Re: Malicious software libraries found in PyPI posing as well known libraries

#174

Post by tclancy »

hannob wrote: post #84

Ok, here's some ugly backstory on this: This problem has been known for a while, yet both the pypi devs and the python security team decided to ignore it. Last year someone wrote his thesis describing python typosquatting and standard library name squatting: http://incolumitas.com/2016/06/08/typosquatting-package-mana... However after that the packages used in this thesis - the most successful one being urllib2 - wer…

>both the pypi devs and the python security team decided to ignore it.

Without trying to downplay the seriousness, I think that's a less-than-charitable take on the bind they felt they were in. It also sounds like there's a crack team of dedicated devs sitting around waiting for something to work on.

Re: Malicious software libraries found in PyPI posing as well known libraries

#175

Post by [deleted] »

hannob wrote: post #84

Ok, here's some ugly backstory on this: This problem has been known for a while, yet both the pypi devs and the python security team decided to ignore it. Last year someone wrote his thesis describing python typosquatting and standard library name squatting: http://incolumitas.com/2016/06/08/typosquatting-package-mana... However after that the packages used in this thesis - the most successful one being urllib2 - wer…

[deleted]

Re: Malicious software libraries found in PyPI posing as well known libraries

#176

Post by hathawsh »

jsty wrote: post #169
hodgesrm wrote: post #151

Earlier quoted context omitted.

This is a scary attack. One partial mitigation is to use a firewall (e.g., Amazon VPC network ACLs) to restrict outbound network traffic to a small number of known addresses like well-known repos. I can't think of a good reason why code in any well-behaved application should be allowed to make random outbound network calls. I think it's also on app developers to rethink the culture of randomly grabbing packages to bu…

> I can't think of a good reason why code in any well-behaved application should be allowed to make random outbound network calls If your application implements webhooks, then there's a valid use case? I'm in complete agreement however that you should default to deny and open up as required.

For security, you should call outbound webhooks using a server dedicated to that purpose, where the main server and webhook caller are connected through an async message passing system such as RabbitMQ. That way you can maintain strict firewall rules on the main server.

Re: Malicious software libraries found in PyPI posing as well known libraries

#177

Post by [deleted] »

zokier wrote: post #166
singularity2001 wrote: post #40

"Success of the attack relies on negligence of the developer" How about package manager managers accept their enourmous responsabilty? urllib vs urllib2, one is a virus? Sorry but that is not "negligence of the developer"

Managing supply chain is one the basic principles of good engineering. Not properly vetting your sources is negligence. The problem of course is that computers are really good at amplifying work, including mistakes. So small mistake, like a typo, could have catastrophic impact, like injecting malware that can take over the whole system.

[deleted]

Re: Malicious software libraries found in PyPI posing as well known libraries

#178

Post by concede_pluto »

eeZah7Ux wrote: post #109
gkya wrote: post #98

Earlier quoted context omitted.

This [1] is npm growth compared to anything else. God this can't be safe nor sane... [1] https://imgur.com/a/enjvR

The left-pad disaster has been predicted well in advance...

There's nothing especially awful about left-pad being its own package, the disaster was because a huge number of developers were betting on npm to somehow be highly available (despite being donated by its admins at no cost and with no committed SLA) rather than vendoring their deps.

Re: Malicious software libraries found in PyPI posing as well known libraries

#179

Post by andrewfong »

mwerty wrote: post #97

How about a Levenshtein distance threshold for new package names to be accepted? I.e only allow names that are different enough from the existing set to avoid typos (or whatever errors we are trying to guard against)?

You don't need a strict ban for this to work either. Maybe just an end-user warning if distance < N and the relative popularity of the two modules is very high. You could also allow users or organizations to explicitly whitelist some names.

Re: Malicious software libraries found in PyPI posing as well known libraries

#180

Post by danjoc »

tclancy wrote: post #174
hannob wrote: post #84

Ok, here's some ugly backstory on this: This problem has been known for a while, yet both the pypi devs and the python security team decided to ignore it. Last year someone wrote his thesis describing python typosquatting and standard library name squatting: http://incolumitas.com/2016/06/08/typosquatting-package-mana... However after that the packages used in this thesis - the most successful one being urllib2 - wer…

>both the pypi devs and the python security team decided to ignore it. Without trying to downplay the seriousness, I think that's a less-than-charitable take on the bind they felt they were in. It also sounds like there's a crack team of dedicated devs sitting around waiting for something to work on.

When I read things like,

https://caremad.io/posts/2013/07/packaging-signing-not-holy-...

I get the impression they don't care about security at all. They seem like children plugging their ears and shouting "nah nah nah" while putting repo users at risk. They've obviously done nothing since that post was made four years ago.

In contrast, Maven central requires signing. Unsurprisingly, Maven central doesn't have typosquatting problems. That's not a coincidence. That's also a strong reason why Java still dominates the enterprise.

If you (the reader) are a PyPi/NPM user, I challenge you to watch this,

https://www.youtube.com/watch?v=pBJafU0p_Nk

and tell me why you shouldn't use a repository manager like Sonatype Nexus which validates package signatures, checks licenses, and does vulnerability scanning.

By itself, package signatures aren't the holy grail? That's not the point. Security is achieved in layers. Too bad they aren't mature enough to understand that.

Post reply on HN