81–90 of 412 posts
I'm surprised the reverse fully-qualified domain name (FQDN) model used by Java isn't more widely adopted. If you want to upload artifacts to the main repository (Maven Central) you first need to show ownership of a particular domain. For example, via a DNS TXT record (example [1]). Would make these kind of attacks a lot more difficult. [1] https://issues.sonatype.org/browse/OSSRH-61509
To update existing non-maintained public packages, mostly because they were on. Net framework and a lot moved to .net core.
In visual studio you can set the priority of where packages have to be checked. My own package repo has a higher priority.
I never thought about using it as an attack vector though.
And I know it's not perfect, but in Python if you use Poetry means you get a poetry.lock file with package hashes built in, so that's something.
The real solution is to design and build software components that can be finished , so they can be ruthlessly vetted - rather than the endless churn of updates.
> The packages had preinstall scripts that automatically launched a script to exfiltrate identifying information from the machine as soon as the build process pulled the packages in. Pre and post install scripts in NPM packages are such a terrible idea. Even when it’s not malware, it usually just a nagging donation request with a deliberate “sleep 5” to slow down your build and keep the text displayed.
pkg managers that do have that: cargo (build.rs), pip (setup.py), npm (install scripts), apt/rpm/pacman (postinstall hooks)
Maybe the only exceptions are Go and Java package managers?
> The packages had preinstall scripts that automatically launched a script to exfiltrate identifying information from the machine as soon as the build process pulled the packages in. Pre and post install scripts in NPM packages are such a terrible idea. Even when it’s not malware, it usually just a nagging donation request with a deliberate “sleep 5” to slow down your build and keep the text displayed.
I don't understand why people keep endlessly complaining about postinstall scripts. Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, and npm itself is literally a tool for installing code to execute later , so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. This is really a complete n…
And yes, you want to sandbox the install too anyway, but it at least needs permissions enough to do its job, i.e. interact with the network somehow. (Although I’m working on a tool to make that fully deterministic so it can never exfiltrate anything.)
There’s also the possibility that there’s no “execute” step at all, like installing a dependency tree just to inspect source, or in theory being able to skip auditing unused code paths.
Earlier quoted context omitted.
Yeah, but at least with PATs (not sure about other token types), you can't scope them to a particular repo, so whenever you need to allow something to even see a private repo or write to a public repo, the token you supply to allow that can do that for all repos and that alone is potentially really destructive. I am not sure if there is a good reason for why PATs can't be scoped to a repository, because if they were…
Worse: you can’t even scope it to an org, and some integration points are only available to org owners! GitHub is terrible.
Earlier quoted context omitted.
Someone will eventually update deps, not necessarily CI. But now that devs machine is compromised. The attacker probably only has a small window of time after it gets in, but it should be long enough to exfiltrate dot-files and the source code of whatever it gets included in. Now they have ssh keys (mine are on a yubikey), and the GitHub url. They can further push malicious code into the repo.
I would hope most SSH keys are password-encrypted if not protected by a hardware token like yours, but I agree that the "unscoped-source" Gemfile syntax is a huge vulnerable hole, and a bad one. I'm just confused about how what seems like a pretty uncommon operation led to such an immediate response and code execution from Shopify. (I also don't think it's true that the attacker has a "small window of time"—as soon a…
That is insane that any company allowed this to happen. ""That said, we consider the root cause of this issue to be a design flaw (rather than a bug) in package managers that can be addressed only through reconfiguration," a Microsoft spokesperson said in the email." No, npm has scopes for a reason, why would that not fix this issue?
When I first used maven, I was appalled by how hard it was to prevent it from accessing maven central. And horrified to see karaf trying to resolve jars from maven central at run time. What a horrible set of defaults. This behaviour should be opt-in, disabled by default, not opt-out through hard to discover and harder to verify configuration settings.