38 ms·

Methods to deal with malicious actors in your system: - Require toilsome identity verification. Things that are in short supply and are difficult to get and un

Methods to deal with malicious actors in your system: - Require toilsome identity verification. Things that are in short supply and are difficult to get and uniquely identify a person. Examples include a phone number, credit card, driver's license, mailed letter, etc. - Require a referral, both for accounts and for new packages. Don't allow a signup unless the user has a referral code generated by another user with good karma. This isn't fool-proof, as a user that does get an account can then generate more accounts. But it makes it easier to revoke them en-masse, and forces users to be more scrupulous about who they refer, as you can block the referrer as well as the malicious user. - Require community review, both of new users, and new packages. New users/packages are sent to a mailing list of moderators and somebody has to approve it, but someone who notices a problem can also reject it, even after it's been mistakenly approved. Slower, but there's more eyeballs to spot malicious stuff. This is more common among open source projects. (Growing your moderator list is important, as well as automating as much of the review process as possible; obviously PyPI currently has a shortage of moderators, but they should have a huge number of them by now!) - Don't allow new users to do certain things until enough time has passed or they have accrued enough karma points. May require fixing bugs, answering questions, etc; work which benefits the community and most malicious actors wouldn't invest the time and effort in. Again not fool-proof, but definitely increases the time and difficulty for successful attacks. - Captchas. These can obviously be worked around, but are a minimum-effort way to avoid bot signups. For better defense-in-depth, combine multiple methods.

nonethewiser 3y ago
What about some testnet that allows people to push things up as a test? That seems like a valid need but a source of lots of garbage at the same time.
- mplewis 3y ago
  This is what https://test.pypi.org/ https://test.pypi.org/ is for.
Hnrobert42 3y ago
These are good suggestions. I also like @BozeWolf’s suggestion below about charging for new accounts. You could even do a combo. Like $25 sign up. Free with referral.
pimlottc 3y ago
Of course, it should also be noted that these will create burdens for legitimate users as well, in some cases disproportionately (e.g. new developers will have a harder time getting referrals).
- genericone 3y ago
  If it prevents coding classes and bootcamps from pushing junk onto pypi/npm as an exercise of the class, I'm all for it.
  - circuit10 3y ago
    New developers can also create genuinely new and useful things, some people (like me) learn by creating (hopefully) useful things as it’s more motivating
    - raverbashing 3y ago
      You can always leave it on github or some similar service, you don't need to "pollute the global namespace for your pet project" And yes you can install it from pip, etc from there
      - circuit10 3y ago
        But aren’t people meant to be able to push useful things to pip? These developers might not even be new, they might just not talk about it online much, or they could be new but fast learners, so these projects could still be things that many other people want
        raverbashing 3y ago
        If it's really useful (and it has users beside the author) yeah, but I wouldn't upload a 30min project just because you feel like it Pip is already full of crap projects, I don't care if you're a 'fast learner', and you could be clobbering a name (or a similar name) to a more important package
woodruffw 3y ago
I posted a variant of this comment below, but for here as well: the single greatest challenge with any additional method here is operational burden. New methods for ensuring the authenticity of users cannot substantially increase the load on PyPI's maintainers without compromising the other activities that keep PyPI well-maintained (like developing and reviewing features, administrating the running instance itself, and addressing baseline operational overhead from locked-out users, etc.). A pernicious thing about this problem is that even the methods that appear to devolve time away from the maintainers (like community review) quietly increase operational burden: they require effort to be allocated to support for those systems, require maintenance and administration of the "trusted list," etc.
nmstoker 3y ago
What about some method of "moderate to get upload credit"? Obviously not full moderation (as you don't trust these people) but you could have them fed a few basic tasks that support moderation. They would be give a selection of tasks, some of which overlap with tasks done by trusted people. If the user answers consistently with the trusted person, they get some credit. When a few such users show consensus on the non-overlapping tasks, those answers get accepted.
bscphil 3y ago
> For better defense-in-depth, combine multiple methods. It really starts to sound like we are reinventing Linux distributions. A strong vetting process and barriers to entry are why Linux distributions remain free of malware in their repositories. AFAIK no Linux distribution has ever been found distributing malware in an official repository (though I'd be interested if anyone knows of an exception).
- eesmith 3y ago
  No Linux distribution comes close to distributing the diversity of packages available from PyPI. I had a package distributed by DebianScience. It was essentially impossible to get them to upgrade. 'malware' is a broad word. I know some Debian developers have characterized Debian-distributed software as having a "timebomb". Does that count?
  - ploxiln 3y ago
    It was Xscreensaver, written by JWZ. He was pissed that debian distributed old versions, so he put in a timebomb that would make it stop working on a certain date. I kinda forget the details, but still I wouldn't consider this malware, it's not something you would worry about trying to exfiltrate credentials, run a cryptominer, open a backdoor shell, etc. It just disables itself with a taunting message, harmless really. Another famous case was when debian patched OpenSSL to fix an uninitialized-memory compiler warning, way back 20 years ago, and other than PID this was the only entropy mixed in before generating keys at the time, so there was a couple months when only 65535 different ssh keys could be generated on such systems, and it's pretty easy and fast to just check them all. Still today (or until very recently) there was a special check to reject usage of such set of weak keys that were generated in those ill-fated 2 months. Still, really nothing like malware. Just a huge security bug. Those happen occasionally (e.g. heartbleed, not debian specific ofc). So like 2 notable cases of less-than-optimal software prepared for users by the debian project? But not malware.
    - eesmith 3y ago
      > he put in a timebomb that would make it stop working on a certain date I wrote 'some Debian developers have characterized [it] as having a "timebomb"'. because I do not agree with that assessment. It did not actually stop working on a certain date. It displayed a warning dialog box on the screen saver lock screen saying the package was out of date. Here is the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 Here is the relevant code: https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2bbe6e852e17989135d762d/driver/demo-Gtk.c#L5295 https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2... Nothing there about no longer working. (If "stop working on a certain date" makes something a time bomb, then expired certifications are certainly in Debian, like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 linking to https://bugs.chromium.org/p/chromium/issues/detail?id=664177 https://bugs.chromium.org/p/chromium/issues/detail?id=664177 "the [Certificate Transparency] information has a built-in build-time bomb of 10 weeks".) Okay, "time bombs" are not malware. Got it. My main point remains, Linux distributions handle far fewer packages than PyPI. "Debian comes with over 59000 packages" says https://www.debian.org/intro/about https://www.debian.org/intro/about and PyPI has 455,474 projects says https://pypi.org/ https://pypi.org/. Can Debian developers handle 7x more packages? Almost certainly not. They couldn't even handle my software. If a package maintainer already can't detect a "time bomb" with a huge warning message in the code, then why should I believe they are able to detect more subtle malware, especially with a 7x higher maintenance load? I write specialist software with only a few thousand users world-wide. Do you really think each of the distros will have the people who are able to review and integrate my code into the distro at the same level as they do xscreensaver? More realistically, they will reject my package as being out of scope, leaving me ... back at PyPI.
reaperman 3y ago
> Captchas. These can obviously be worked around... Best to not consider this a barrier at all. I helped build a lot of systems to bypass these and the "guarantees" they offer are truly "de minimus". Phone numbers and credit cards are are only slightly better. The real answer is to determine how much value a successful compromise of your service can generate, and combine enough barriers to clearly exceed that value. Some criminals are very business-savvy, but many have poor judgement of value and will overspend on marginal cost-of-acquisition and try to "make up for it in volume", so it's important to be obviously not worth the expense. Unfortunately for PyPI, there's a wide gamut of value gained from compromise from a wide variety of different actors. And for some of those actors, the potential value gained is existential, so they are willing to spend anything to compromise PyPI, and they have incredible resources. So then PyPI has to make itself more expensive than compromising Windows/SS7/Linux/iOS/Office365/AT&T/etc/etc. And that's a very difficult field to find yourself competing in. Shameless plug: http://resolved.dominuslabs.com http://resolved.dominuslabs.com feel free to reach out for custom work - specializing in accessing gated sites for new search engines to do better web crawling, scraping public data, etc.
- throwaway892238 3y ago
  None of the barriers are fool-proof, but they are layers of defense. When adding defensive layers, you need a cost comparison of how much time and money it costs you, versus how much time and money it costs the attacker. If it costs you $0 recurring and 5 developer days, and it costs the attacker 1 human solving 1 captcha per 1 form submission, then it's probably worth doing it, if only to stop randomly-scanning botnets and reduce the signal-to-noise on your detection capabilities. (I know AI is getting better at automated solving, dunno if they're all broken yet)
  - reaperman 3y ago
    > you need a cost comparison of how much time and money it costs you, versus how much time and money it costs the attacker. Not quite! It's actually "how much money your countermeasures costs the attacker to beat, versus how much money it gains the attacker to beat your countermeasures". The attacker doesn't care if you spent $1 or $1 billion on it, they only care what it costs them vs. gains them. If it gains a lot, there are usually ways to fund the effort, no matter how large. There's usually an enormous mismatch between your budget and the attackers' budgets (in either direction), as well as a massive adjustment for purchasing-power-parity. This isn't a "near-peer" fight where you're trying to "outspend" the attackers using efficient techniques to exhaust their budget before your budget is exhausted. This is a situation where there are nomadic bandits, regional pirates, FAANGs, and entire governments where you want to just make it so they look at your system and go "nah skip that. we'll do this another way entirely by getting access to a different company's system instead".
ryan29 3y ago
I think domain verified namespaces would make a difference. If I own example.com, it makes sense for my namespace to be @example.com (pypi.org/@example.com/project). If all namespaces were domain based it would reduce impersonation and confusion while making it much easier to assess trustworthiness. If I can definitively associate a namespace across GitHub, PyPi, the internet, I can get a much better idea of whether or not I should trust someone. I also think that could evolve into some type of attestations about money already being spent. I call it collateral attestation. For example, if I use GitHub Sponsors to donate to a project, GitHub could attest to that. If I donate $50 to the PyPi project, they get an attestation that someone donated $50 to them and I get an attestation that I donated $50 to someone. Even if it's only domain validated namespaces, at least that's something that costs a little bit of money every year and it scales without a lot of human intervention compared to most other ideas.
- paulddraper 3y ago
  I assume ownership would follow the domain? if it gets transferred, then the ownership of packages gets transferred too?
  - ryan29 3y ago
    No. I would use domain as a vanity pointer and a permanent account as the source of truth that clients use to download packages. You have to assume the domain can be dropped and re-registered by a bad actor, so a permanent account with proper package signing is really the only way to ensure you're not getting packages that are the result of an account takeover. All a domain based namespace really does is help to get rid of impersonation and the confusion causes by squatting and mismatched namespaces everywhere. I think it helps in evaluating trustworthiness the first time you add a package to a project, but you still need package locking and signing to ensure you're only getting packages from the person or organization you've trusted.
matheusmoreira 3y ago
Linux distribution maintainers already do all of those things and probably more. It's always interesting to see other projects rediscover these lessons multiple times.
quickthrower2 3y ago
Or don’t have a system? What if you installed stuff via a git (not necessarily github) url/tag? Puts the onus on users to verify. Use checksums to avoid upstream changes you didn’t explicitly accept. No different than cloning a repo from a risk perspective (just as risky but no more so). This removes any implicit seal of approval. Companies like malwarebytes could monitor and maintain blacklists or whitelists. Sign up to multiple lists if paranoid.
- thayne 3y ago
  That's how go does it, and it has some drawbacks: Things break if the git url changes, which is more likely than the package name changing. It complicates using a fork, or local version of a package. Having the url once in a package manifest instead of repeated in every file that importa,like go dows, would probably help. It can make discovering the package you need more difficult.
  - aunderscored 3y ago
    Go has vanity URLs for the first, and go module files have replace statements to redirect imports to other names or local directories.
    - thayne 3y ago
      > Go has vanity URLs for the first In theory, maybe. In practice, I haven't seen vanity urls used very much in go projects, and for it to completely solve the problem you need to use the vanity url from the very beginning and you can't ever change the vanity url. It also requires you to have your own domain.
strogonoff 3y ago
Identity verification is the only reliable option for popular public package registries that want to avoid becoming a cesspool of malware. The problem with identity verification is that it can be expensive for you, the registry (reliable implementations require things up to video call verification in case of doubt), and risky for your users (who will have to trust your or your verification partner’s infosec practices with their PII). Ideally either of those, but if you screw up—both. It’s also crucial to remember that identity verification is never a guarantee: you cannot dispense with any pre-existing measures, like manual package review and user reports, to recoup the costs. All in all, it is inevitably an expensive undertaking and a sad example of the tragedy of the commons.

nonethewiser 3y ago

What about some testnet that allows people to push things up as a test? That seems like a valid need but a source of lots of garbage at the same time.

mplewis 3y ago
This is what https://test.pypi.org/ https://test.pypi.org/ is for.

Hnrobert42 3y ago

These are good suggestions. I also like @BozeWolf’s suggestion below about charging for new accounts. You could even do a combo. Like $25 sign up. Free with referral.

pimlottc 3y ago

Of course, it should also be noted that these will create burdens for legitimate users as well, in some cases disproportionately (e.g. new developers will have a harder time getting referrals).

genericone 3y ago
If it prevents coding classes and bootcamps from pushing junk onto pypi/npm as an exercise of the class, I'm all for it.
- circuit10 3y ago
  New developers can also create genuinely new and useful things, some people (like me) learn by creating (hopefully) useful things as it’s more motivating
  - raverbashing 3y ago
    You can always leave it on github or some similar service, you don't need to "pollute the global namespace for your pet project" And yes you can install it from pip, etc from there
    - circuit10 3y ago
      But aren’t people meant to be able to push useful things to pip? These developers might not even be new, they might just not talk about it online much, or they could be new but fast learners, so these projects could still be things that many other people want
      - raverbashing 3y ago
        If it's really useful (and it has users beside the author) yeah, but I wouldn't upload a 30min project just because you feel like it Pip is already full of crap projects, I don't care if you're a 'fast learner', and you could be clobbering a name (or a similar name) to a more important package

woodruffw 3y ago

I posted a variant of this comment below, but for here as well: the single greatest challenge with any additional method here is operational burden. New methods for ensuring the authenticity of users cannot substantially increase the load on PyPI's maintainers without compromising the other activities that keep PyPI well-maintained (like developing and reviewing features, administrating the running instance itself, and addressing baseline operational overhead from locked-out users, etc.). A pernicious thing about this problem is that even the methods that appear to devolve time away from the maintainers (like community review) quietly increase operational burden: they require effort to be allocated to support for those systems, require maintenance and administration of the "trusted list," etc.

nmstoker 3y ago

What about some method of "moderate to get upload credit"? Obviously not full moderation (as you don't trust these people) but you could have them fed a few basic tasks that support moderation. They would be give a selection of tasks, some of which overlap with tasks done by trusted people. If the user answers consistently with the trusted person, they get some credit. When a few such users show consensus on the non-overlapping tasks, those answers get accepted.

bscphil 3y ago

> For better defense-in-depth, combine multiple methods. It really starts to sound like we are reinventing Linux distributions. A strong vetting process and barriers to entry are why Linux distributions remain free of malware in their repositories. AFAIK no Linux distribution has ever been found distributing malware in an official repository (though I'd be interested if anyone knows of an exception).

eesmith 3y ago
No Linux distribution comes close to distributing the diversity of packages available from PyPI. I had a package distributed by DebianScience. It was essentially impossible to get them to upgrade. 'malware' is a broad word. I know some Debian developers have characterized Debian-distributed software as having a "timebomb". Does that count?
- ploxiln 3y ago
  It was Xscreensaver, written by JWZ. He was pissed that debian distributed old versions, so he put in a timebomb that would make it stop working on a certain date. I kinda forget the details, but still I wouldn't consider this malware, it's not something you would worry about trying to exfiltrate credentials, run a cryptominer, open a backdoor shell, etc. It just disables itself with a taunting message, harmless really. Another famous case was when debian patched OpenSSL to fix an uninitialized-memory compiler warning, way back 20 years ago, and other than PID this was the only entropy mixed in before generating keys at the time, so there was a couple months when only 65535 different ssh keys could be generated on such systems, and it's pretty easy and fast to just check them all. Still today (or until very recently) there was a special check to reject usage of such set of weak keys that were generated in those ill-fated 2 months. Still, really nothing like malware. Just a huge security bug. Those happen occasionally (e.g. heartbleed, not debian specific ofc). So like 2 notable cases of less-than-optimal software prepared for users by the debian project? But not malware.
  - eesmith 3y ago
    > he put in a timebomb that would make it stop working on a certain date I wrote 'some Debian developers have characterized [it] as having a "timebomb"'. because I do not agree with that assessment. It did not actually stop working on a certain date. It displayed a warning dialog box on the screen saver lock screen saying the package was out of date. Here is the bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703 Here is the relevant code: https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2bbe6e852e17989135d762d/driver/demo-Gtk.c#L5295 https://github.com/Zygo/xscreensaver/blob/379ea5d57c212863d2... Nothing there about no longer working. (If "stop working on a certain date" makes something a time bomb, then expired certifications are certainly in Debian, like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844631 linking to https://bugs.chromium.org/p/chromium/issues/detail?id=664177 https://bugs.chromium.org/p/chromium/issues/detail?id=664177 "the [Certificate Transparency] information has a built-in build-time bomb of 10 weeks".) Okay, "time bombs" are not malware. Got it. My main point remains, Linux distributions handle far fewer packages than PyPI. "Debian comes with over 59000 packages" says https://www.debian.org/intro/about https://www.debian.org/intro/about and PyPI has 455,474 projects says https://pypi.org/ https://pypi.org/. Can Debian developers handle 7x more packages? Almost certainly not. They couldn't even handle my software. If a package maintainer already can't detect a "time bomb" with a huge warning message in the code, then why should I believe they are able to detect more subtle malware, especially with a 7x higher maintenance load? I write specialist software with only a few thousand users world-wide. Do you really think each of the distros will have the people who are able to review and integrate my code into the distro at the same level as they do xscreensaver? More realistically, they will reject my package as being out of scope, leaving me ... back at PyPI.

reaperman 3y ago

> Captchas. These can obviously be worked around... Best to not consider this a barrier at all. I helped build a lot of systems to bypass these and the "guarantees" they offer are truly "de minimus". Phone numbers and credit cards are are only slightly better. The real answer is to determine how much value a successful compromise of your service can generate, and combine enough barriers to clearly exceed that value. Some criminals are very business-savvy, but many have poor judgement of value and will overspend on marginal cost-of-acquisition and try to "make up for it in volume", so it's important to be obviously not worth the expense. Unfortunately for PyPI, there's a wide gamut of value gained from compromise from a wide variety of different actors. And for some of those actors, the potential value gained is existential, so they are willing to spend anything to compromise PyPI, and they have incredible resources. So then PyPI has to make itself more expensive than compromising Windows/SS7/Linux/iOS/Office365/AT&T/etc/etc. And that's a very difficult field to find yourself competing in. Shameless plug: http://resolved.dominuslabs.com http://resolved.dominuslabs.com feel free to reach out for custom work - specializing in accessing gated sites for new search engines to do better web crawling, scraping public data, etc.

throwaway892238 3y ago
None of the barriers are fool-proof, but they are layers of defense. When adding defensive layers, you need a cost comparison of how much time and money it costs you, versus how much time and money it costs the attacker. If it costs you $0 recurring and 5 developer days, and it costs the attacker 1 human solving 1 captcha per 1 form submission, then it's probably worth doing it, if only to stop randomly-scanning botnets and reduce the signal-to-noise on your detection capabilities. (I know AI is getting better at automated solving, dunno if they're all broken yet)
- reaperman 3y ago
  > you need a cost comparison of how much time and money it costs you, versus how much time and money it costs the attacker. Not quite! It's actually "how much money your countermeasures costs the attacker to beat, versus how much money it gains the attacker to beat your countermeasures". The attacker doesn't care if you spent $1 or $1 billion on it, they only care what it costs them vs. gains them. If it gains a lot, there are usually ways to fund the effort, no matter how large. There's usually an enormous mismatch between your budget and the attackers' budgets (in either direction), as well as a massive adjustment for purchasing-power-parity. This isn't a "near-peer" fight where you're trying to "outspend" the attackers using efficient techniques to exhaust their budget before your budget is exhausted. This is a situation where there are nomadic bandits, regional pirates, FAANGs, and entire governments where you want to just make it so they look at your system and go "nah skip that. we'll do this another way entirely by getting access to a different company's system instead".

ryan29 3y ago

I think domain verified namespaces would make a difference. If I own example.com, it makes sense for my namespace to be @example.com (pypi.org/@example.com/project). If all namespaces were domain based it would reduce impersonation and confusion while making it much easier to assess trustworthiness. If I can definitively associate a namespace across GitHub, PyPi, the internet, I can get a much better idea of whether or not I should trust someone. I also think that could evolve into some type of attestations about money already being spent. I call it collateral attestation. For example, if I use GitHub Sponsors to donate to a project, GitHub could attest to that. If I donate $50 to the PyPi project, they get an attestation that someone donated $50 to them and I get an attestation that I donated $50 to someone. Even if it's only domain validated namespaces, at least that's something that costs a little bit of money every year and it scales without a lot of human intervention compared to most other ideas.

paulddraper 3y ago
I assume ownership would follow the domain? if it gets transferred, then the ownership of packages gets transferred too?
- ryan29 3y ago
  No. I would use domain as a vanity pointer and a permanent account as the source of truth that clients use to download packages. You have to assume the domain can be dropped and re-registered by a bad actor, so a permanent account with proper package signing is really the only way to ensure you're not getting packages that are the result of an account takeover. All a domain based namespace really does is help to get rid of impersonation and the confusion causes by squatting and mismatched namespaces everywhere. I think it helps in evaluating trustworthiness the first time you add a package to a project, but you still need package locking and signing to ensure you're only getting packages from the person or organization you've trusted.

matheusmoreira 3y ago

Linux distribution maintainers already do all of those things and probably more. It's always interesting to see other projects rediscover these lessons multiple times.

quickthrower2 3y ago

Or don’t have a system? What if you installed stuff via a git (not necessarily github) url/tag? Puts the onus on users to verify. Use checksums to avoid upstream changes you didn’t explicitly accept. No different than cloning a repo from a risk perspective (just as risky but no more so). This removes any implicit seal of approval. Companies like malwarebytes could monitor and maintain blacklists or whitelists. Sign up to multiple lists if paranoid.

thayne 3y ago
That's how go does it, and it has some drawbacks: Things break if the git url changes, which is more likely than the package name changing. It complicates using a fork, or local version of a package. Having the url once in a package manifest instead of repeated in every file that importa,like go dows, would probably help. It can make discovering the package you need more difficult.
- aunderscored 3y ago
  Go has vanity URLs for the first, and go module files have replace statements to redirect imports to other names or local directories.
  - thayne 3y ago
    > Go has vanity URLs for the first In theory, maybe. In practice, I haven't seen vanity urls used very much in go projects, and for it to completely solve the problem you need to use the vanity url from the very beginning and you can't ever change the vanity url. It also requires you to have your own domain.

strogonoff 3y ago

Identity verification is the only reliable option for popular public package registries that want to avoid becoming a cesspool of malware. The problem with identity verification is that it can be expensive for you, the registry (reliable implementations require things up to video call verification in case of doubt), and risky for your users (who will have to trust your or your verification partner’s infosec practices with their PII). Ideally either of those, but if you screw up—both. It’s also crucial to remember that identity verification is never a guarantee: you cannot dispense with any pre-existing measures, like manual package review and user reports, to recoup the costs. All in all, it is inevitably an expensive undertaking and a sad example of the tragedy of the commons.