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

Shai-Hulud Returns: Over 300 NPM Packages Infected

helixguard.ai

Post reply on HN
Print view View original

751–760 of 797 posts

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#751

Post by gred »

p3rspective wrote: post #727
gred wrote: post #74

Earlier quoted context omitted.

NPM has about 4 million packages, Maven Central has about 3 million packages. If this were true, wouldn't there have been at least one Maven attack by now, considering the number of NPM attacks that we've seen?

Make no mistake, Maven Central does get multiple malware components uploaded each year, though not nearly to the same extent as npm or pypi. Sonatype (my former employer) just doesn't report on these publicly each time it happens. It's not an isolated problem but certainly harder to do with maven.

I assume you're talking about malware uploaded to new artifact coordinates (possibly named so as to try to confuse users), not hijacking of existing artifact coordinates (group ID, artifact ID)?

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#752

Post by mbreese »

woodruffw wrote: post #750
mbreese wrote: post #738

Earlier quoted context omitted.

What person do you want to remove from the process?

The person who intermediates the trust relationship between the index and the source repository. There’s no reason for the credential that links those two parties to be intermediated by a human; they’re two machine services talking. (You obviously can’t disintermediate the human from maintenance or development!)

But that’s the person I think is mandatory.

You’re saying that whatever is in the source repository should be uploaded in the npm index, right? If the code is tagged as release, the built artifact is automatically uploaded to npm. Is that what you’re proposing?

That exactly what got PostHog into this position. The keys to publish to npm were available to an engineer or GitHub to push a malware build into npm automatically. This isn’t a technical issue… it’s a process issue. I don’t see the problem as that the keys were misused. I see the problem as that it was possible to misuse the keys at all. Why do you need that process to be automatic? How often are you pushing new updates?

I would argue that those npm assets/libraries are your work product. That is what your customer needs to use your service. It is a published product from your company. It is too important to allow a new version to be published out to the public without a human in the loop to approve it.

When you have a fully automatic publishing cycle, you’re trading security for convenience. It’s all about how much risk you’re willing to accept. For me, that’s too much of a risk to the reputation to the company. I also think the balance shifts if you’re talking about purely internal assets, having completely automatic ci/cd makes perfect sense for most companies. For me, it is about who is hurt if there is an issue (and you should expect for there to be an issue).

Putting a person in the loop for releasing a product is one way to solve this. It’s not perfect, but at the moment, I think it’s the most secure (for the public).

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#754

Post by collinmanderson »

zahlman wrote: post #715
acdha wrote: post #710

Earlier quoted context omitted.

> Pip does not support this; with uv, use `--exclude-newer`. This appears to require a timestamp; so if you always want things up to X days old you'll have to recalculate. I do this by having my shell init do this: export UV_EXCLUDE_NEWER=$(date -Iu -d "14 days ago") That’s easy to override if you need to but otherwise seamless.

FWIW, I'd like if these tools had an option to prefer the oldest version satisfying the given constraints (rather than the newest, as it is now — probably still a better default).

> prefer the oldest version satisfying the given constraints

The problem is there's no metadata for which versions fix security bugs, and therefore which previous versions are now insecure.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#755

Post by latentsea »

HighGoldstein wrote: post #403
latentsea wrote: post #277

Earlier quoted context omitted.

Having worked on four different enterprise grade C# codebases, they most certainly have plenty of 3rd party dependencies. It would absolutely be the exception to not have 3rd party dependencies.

Yes, but the 3rd party dependencies tend to be conveniences rather than foundational. Easier mapping, easier mocking, easier test assertions, so a more security minded company can very easily just disallow their use without major impact. If it's something foundational to your project then what you're doing is probably somewhat niche. Most of the time there's some dependency from Microsoft that's rarely worse enough t…

I dunno, there's definitely stuff that's convenience related, sure, and then there's stuff that's less so. Things like MediatR, Dapper, Serilog, Refit are all pretty common in .NET projects. There's usually always some library for generating PDFs for reporting purposes etc. The ecosystem of NuGet packages is pretty large. It's definitely not all just Microsoft dependencies, nor is that usually how developers in the ecosystem think in my experience.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#756

Post by QuiEgo »

windward wrote: post #737
QuiEgo wrote: post #666

Earlier quoted context omitted.

¯\_(ツ)_/¯ I'd like to lean into that "YMMV" in my post, I'm coming from low level C that interacts with hardware, can't really speak to higher-level C++. Some things in Rust just don't translate to the way you'd do them in C - e.x. using different types to say if a GPIO pin is input or output adds a ton of boiler plate, but lets the compiler assure you don't mistakenly try and use a pin configured as an input for out…

ZSTs are a choice, if you're not benefiting from them in development time or correctness, why are you making that choice? Rust isn't just C++ with static analysis. The safety is only about 1/3 of what makes me enjoy working with it. Even if I just consider the effort taken before I present something to a compiler, the trait system means I don't spend anywhere near as much time writing copy/copy assignment/move/move a…

Good on you for recognizing what you enjoy and going for it.

I like hardware, always have :).

FWIW, I’ve done embedded at multiple mag 7 companies, and if levels.fyi is to be believed I’m getting paid the same as my peers doing other types of software. There are certainly places that don’t do this though (I hear the defense industry is notorious for this).

The point about the tooling being ghetto is spot on though, that’s part of why Rust is so exciting for us. A package manager?! What is this magic!!!

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#757

Post by Yasuraka »

eptcyka wrote: post #753
Yasuraka wrote: post #742

Earlier quoted context omitted.

Nope. Know the difference.

How is Go any worse or better than Rust when it comes to the ease of adding dependencies?

I read your comment as in, comparing to node, my bad.

With regards to Rust, crates are packages which may include opaque binaries, e.g. serde_derive, and the stdlib is weak, so imports of thousands of lines of code are basically necessary for otherwise fundamental features like async.

It's probably easier to add dependencies in Go, but in the end people/projects don't.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#758

Post by QuiEgo »

FridgeSeal wrote: post #708
QuiEgo wrote: post #581

Earlier quoted context omitted.

Thank you for the clarification, that's exactly what I was trying to say :). Perhaps another way to phrase this: in Rust, you spend more time telling the compiler how your code is expected to work (making the borrow checker happy, adding sync traits on objects you "know" are thread safe because of how you use them or assurances the underlying hardware provides, etc etc etc). In return, the compiler does a lot of work…

Remind me again, how the”sufficiently senior dev” approach is panning out for places that are swapping off C/C++? Because from here, it seems like they’re having a great time, which is extremely at-odds with your comment.

My experience in low-level stuff has been a mirror of the Linux kernel trying to take up Rust. Some people love it and fight hard for it, some hate it and fight hard against it, but most just see it as another tool in the toolbox and don't have strong feelings.

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#759

Post by woodruffw »

mbreese wrote: post #752
woodruffw wrote: post #750

Earlier quoted context omitted.

The person who intermediates the trust relationship between the index and the source repository. There’s no reason for the credential that links those two parties to be intermediated by a human; they’re two machine services talking. (You obviously can’t disintermediate the human from maintenance or development!)

But that’s the person I think is mandatory. You’re saying that whatever is in the source repository should be uploaded in the npm index, right? If the code is tagged as release, the built artifact is automatically uploaded to npm. Is that what you’re proposing? That exactly what got PostHog into this position. The keys to publish to npm were available to an engineer or GitHub to push a malware build into npm automati…

> You’re saying that whatever is in the source repository should be uploaded in the npm index, right? If the code is tagged as release, the built artifact is automatically uploaded to npm. Is that what you’re proposing?

No, I'm saying that the source repository should act as an authentication principal itself. A human should still initiate the release process, but the authentication process that connects the source repository (more precisely CI/CD) to the index should not involve a credential that's implicitly bound to a human identity (because the human's role within a project or company is ephemeral).

As far as I can tell, what got PostHog into this situation wasn't a fully automated release process (very few companies/groups have fully automated processes), but the fact that they had user-created long-lived credentials that an attacker could store and weaponize at a time most convenient to them. That's a problem regardless of whether there's normally a human in the loop or not, because the long-lived credential itself was sufficient for publishing.

(In other words, we basically agree about human approval being good; what I'm saying is that we should formalize human approval without making the authentication scheme explicitly require an intermediating partner who doesn't inherently represent the actual principal, i.e. the source repository.)

Re: Shai-Hulud Returns: Over 300 NPM Packages Infected

#760

Post by woodruffw »

junon wrote: post #748
woodruffw wrote: post #273

Earlier quoted context omitted.

Trusted Publishing addresses the vector here, which is arbitrary persistence and delayed use of credentials by attackers. You're right that it's not a silver bullet (anything claiming to be one is almost certainly a financially induced lie), but it eliminates/foreshortens the attack staging window significantly.

It's not a silver bullet in that it can open up other vectors of much more probable attack. If I have a FOSS project where there are other contributors with write access but not publish access (very common) OIDC now allows them to publish via workflows, opening you up to Jia Tan type attacks. Like I said, if it works for your org, great. Otherwise it can cause bigger problems.

Sorry, what's the threat model in which you're giving people write access to your repository but assuming that they can't publish?

To establish a baseline here: the assumption with Trusted Publishing is that people are already using CI/CD to publish to places like PyPI. All Trusted Publishing does is replace the user-managed credential with a machine-intermediated one.

In other words: if someone had write access to your repository before, Trusted Publishing does not change their privilege, since they could always push a new CI/CD workflow that uses your manual publishing secret directly. All Trusted Publishing does is formalize the treatment of the source repository as a source of truth, and introduce some misuse-resistance properties (short-lived credentials, minimal self-scoping).

If this isn't your user model, that's perfectly fine. But in that case you shouldn't be using CI/CD to publish at all (which is also fine); it's not an issue with Trusted Publishing per se.

Post reply on HN