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

Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

safedep.io

Post reply on HN
Print view View original

271–280 of 329 posts

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#271

Post by gred »

mschuster91 wrote: post #180
gred wrote: post #171

Earlier quoted context omitted.

Your example of security issues in Maven is... npm guys setting up processes to auto-publish infected npm packages into the Maven Central repository? Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade.

> Wake me up when the daily npm security breach headlines are typosquatting stories, not RCE-on-build or RCE-on-upgrade. RCE-on-build/upgrade can be done in Maven if you manage to compromise one of the major Maven plugins, they run at build time. The thing keeping maven safe for now is that most people pin the plugin and dependency versions, with the obvious side effect that it's truly annoying to get all your depend…

> The thing keeping maven safe for now is that most people pin [...] versions

Yes, and also the signing of JARs that are uploaded to the repository, and the fact that most release processes are not fully automated, and the batteries-included standard library which reduces the total number of dependencies, and the fact that a run-of-the-mill third-party library can't execute code at build time, and the very small number of people with credentials to publish new versions of major Maven plugins, etc.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#272

Post by optionalsquid »

amiga386 wrote: post #241
joshkel wrote: post #234

Earlier quoted context omitted.

I'm far from an expert, but this feels like an oversimplification. Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control. Native Ruby Gems execute arbitrary code via extconf.rb. Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorpora…

> Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "compos…

> But nowadays prefer pyproject.toml

Couldn't you accomplish the same thing by adding a malicious [build-system] to a pyproject.toml file? You can pull in arbitrary code by providing exact URLs for requirements:

  [build-system]
  requires = ["hatchling @ https://files.pythonhosted.org/packages/8f/8a/cc1debe3514da292094f1c3a700e4ca25442489731ef7c0814358816bb03/hatchling-1.27.0.tar.gz"]
  build-backend = "hatchling.build"

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#273

Post by [deleted] »

codedokode wrote: post #247
Havoc wrote: post #49

Earlier quoted context omitted.

Unprivileged LXCs get pretty close. Less unified design wise but on some aspects better - kernel escape doesn’t land you on a 0 UID

Namespaces look dangerous to me because they break lot of assumptions software was built on before. For example, sudo relies on /etc/sudoers being accessible only to root. But with unprivileged containers one can easily create a filesystem namespace where /etc/sudoers would contain arbitrary data. I think, SUID bit won't work in container, but there might be other ways to confuse privileged software using containers.…

[deleted]

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#274

Post by DeliciousSeaCow »

btown wrote: post #260
Sohcahtoa82 wrote: post #252

Earlier quoted context omitted.

> At a certain point, is it better to just turn off Dependabot and freeze all NPM packages (minor/patch version and all), rather than continuously update? But then the compliance team gets annoyed because some CVE with a CVSS score of 3.1 that has a patch available sits unfixed.

I wonder if the only thing that will solve this is an insurer or regulator saying that: "A system that automatically pulls updates for dependencies without human review, where said updates are not protected by multi-factor authentication by their respective maintainers, shall not be considered secure." That would wake NPM up at least to the notion that it's absolutely reasonable to require OSS maintainers to press a…

Pretty much what the EU Cyber Resiliency Act says re: OSS due diligence, actually.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#275

Post by gabdpipi »

OhMeadhbh wrote: post #224
gabdpipi wrote: post #149

Earlier quoted context omitted.

Yeah I was thinking the difference between open source and enterprise to mitigate this is a simple hardware security module right? If the attackers spearfish folks who hold “keys to the castle” and everything is digital it’s game over no matter what ecosystem. Those things should be locked down by “something you have” because that’s much more difficult.

What will cryptography buy you in this instance? Do digital signatures imply virtuous behaviour? Does the lack of a signature imply vice?

It’s not just cryptography when a developers password manager gets compromised and all, the hacker is “in”.

If it’s secured by a hardware key, they need to have the key physically.

Two step could work as well with the proper Authenticator.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#276

Post by OhMeadhbh »

gabdpipi wrote: post #275
OhMeadhbh wrote: post #224

Earlier quoted context omitted.

What will cryptography buy you in this instance? Do digital signatures imply virtuous behaviour? Does the lack of a signature imply vice?

It’s not just cryptography when a developers password manager gets compromised and all, the hacker is “in”. If it’s secured by a hardware key, they need to have the key physically. Two step could work as well with the proper Authenticator.

IPCMSes make it somewhat easy to MitM SMS. If your system poops a cookie in the wrong place it doesn't matter if the secret is in someone's head or if it's in a hardware dongle, like you say... the hacker is "in".

My recommendation for bad guys is to not attack the part of the system where it is strong. Just sniff around a bit until you find the weak part and attack that.

Also remember most devs couldn't use a static analysis tool to save their lives (which is why mythos is relevant.) I suspect that a 15 year old copy of Fortify or CoVerity could find bugs mythos missed.

And if that doesn't work, just start scanning github repos for entropy. That's where the credentials that were accidentally published live.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#277

Post by amiga386 »

bakkoting wrote: post #249
amiga386 wrote: post #241

Earlier quoted context omitted.

> Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "compos…

> most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages Technically true, but wheels can include a `.pth` which will run arbitrary code as soon as Python is started, which is only marginally less dangerous. Recently exploited in the LiteLLM attack.

That appears to be an exploitable feature of the language, not the package manager per se.

We could then add the philosophical question of asking what's the difference between:

1. Adding malicious code to a package's .pth file that's evaluated automatically on every python invocation

2. Adding malicious code to the package itself that's evaluated automatically on every python invocation _that uses that package_

Packaging systems that don't run arbitrary code when you install a package are more trustworthy than ones that do, but there's still the essential trust you have to place in all code you're installing, directly and indirectly.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#278

Post by amiga386 »

optionalsquid wrote: post #272
amiga386 wrote: post #241

Earlier quoted context omitted.

> Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "compos…

> But nowadays prefer pyproject.toml Couldn't you accomplish the same thing by adding a malicious [build-system] to a pyproject.toml file? You can pull in arbitrary code by providing exact URLs for requirements: [build-system] requires = ["hatchling @ https://files.pythonhosted.org/packages/8f/8a/cc1debe3514da292094f1c3a700e4ca25442489731ef7c0814358816bb03/hatchling-1.27.0.tar.gz"] build-backend = "hatchling.build"

That's a very visible Ken Thompson style attack. The modern expectation is that PyPI would be evaluating this build-system section and would only accept build-systems that they trust to turn package distributions into wheels, and the end users only need the wheels. If you need a specific version of hatchling that they know of, that's fine. If you need something they haven't heard of, they should say no.

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#279

Post by skydhash »

joshkel wrote: post #250
amiga386 wrote: post #241

Earlier quoted context omitted.

> Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "compos…

> But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. Yes, and these are positive changes. But they aren't security boundaries, and they don't mean that pip won't execute arbitrary code: a malicious update could ship an update with sdist instead of wheels, a malicious pyproject.toml could provid…

> Early JS had a relatively anemic standard library in the early days, and NPM made code reuse dramatically simpler than before. This normalized the use of large and deep dependency trees among JS projects.

This always seems like a very convenient excuse. C also have a very small standard library. And unless you're doing system programming, you often have to find utility library. It's just that those libraries tries to solve their domain instead of splitting themselves into molecules. Before npm, we had good js libraries too like jQuery as a fundamental one, backbone.js, dropzone.js,... where you import a few files (and vendor them in your project) and be done with it.

The issue with NPM is that it led to the creation of weird ecosystem like babel, webpack, eslint,... where instead of having a good enough solution, it was plugins ad infinitum. And other maintainers started doing the same thing, splitting their libraries, and writing libraries where a gist or a blog post would be enough[0]. Cargo is suffering the same[1]

[0]: https://github.com/Rob--W/proxy-from-env/blob/master/index.j...

[1]: https://docs.rs/is_executable/latest/src/is_executable/lib.r...

Re: Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

#280

Post by mapontosevenths »

staticassertion wrote: post #257
mapontosevenths wrote: post #77

Earlier quoted context omitted.

Despite what some people will tell you (including many in the security indistry), Docker is not a strong security boundary, and it should not be treated as one. It shares a kernel with the running system. It reminds me of the good old days when people would hand out low privilege Linux accounts and rely on the kernel to prevent privilige escalation. Docker is literally the same thing, just with extra steps. Especiall…

Docker is a lot more than just an unprivileged user. In particular, it comes with a seccomp filter. A lot of LPEs are blocked by that filter. Docker is actually a quite decent security boundary - in this case the attackers did not attempt to subvert docker by attacking the kernel attack surface, they attacked a weak configuration via the docker socket being mounted. The reason you don't use a "grown up VM" is because…

> the difference between "nothing" and "docker" is actually pretty huge

You've got me there, but it's not really saying much.

Seccomp, for example, is nice, but... It blocks ~44 system calls, and leaves 300 plus exposed. Any memory corruption issue in those remaining calls remain wide open. So better than nothing? Absolutely, but it leads to a false sense of security. I know actual security researchers that intentionally run malware inside Docker and think they're safe. They're not.

Then we can talk about docker itself. It had something like 6 public CVE's related to full escapes last year. If your patch cycle takes 30 days then you spend about half the year with a full, public, escape known. Even if you patched those all on day one you spent most of the year vulnerable to one of the many Kernel vulns that it doesn't stop. On any given calendar day it's statistically likely there is at LEAST one way to escape publicly known and unpatched.

So, yeah. It beats nothing by a huge margin, but it's WORSE than nothing if you think it's safe to run arbitrary untrusted code in. That was never what it was for, it's just what people treat it as. It's not a VM, wasn't designed to be, and people need to stop pretending it is.

Post reply on HN