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

NPM debug and chalk packages compromised

aikido.dev

Post reply on HN
Print view View original

211–220 of 796 posts

Re: NPM debug and chalk packages compromised

#211

Post by aabbccsmith »

simpaticoder wrote: post #121

I've come to the conclusion that avoiding the npm registry is a great benefit. The alternative is to import packages directly from the (git) repository. Apart from being a major vector for supply-chain attacks like this one, it is also true that there is little or no coupling between the source of a project and its published code. The 'npm publish' step takes pushes local contents into the registry, meaning that a ma…

npm's recent provenance feature fixes this, and it's pretty easy to setup. It will seriously help prevent things like this from ever happening again, and I'm really glad that big packages are starting to use it.

Re: NPM debug and chalk packages compromised

#212

Post by alexellisuk »

junon wrote: post #202
alexellisuk wrote: post #197

Earlier quoted context omitted.

How did simply opening this email in something like Gmail or a desktop client result in it being able to compromise NPM packages under your control? I'm just curious - and as a word of warning to others so we can learn. I may be missing some details, I've read most of the comments on the page.

I clicked the link like a genius :)

:-( How did the link hijack your password/2fa? Or did you also enter some stuff on the form?

Re: NPM debug and chalk packages compromised

#213

Post by semverbad »

edent wrote: post #131
goku12 wrote: post #43

Developer account got hijacked through phishing. @junon acknowledged this readily and is trying to get it sorted. Meanwhile, this is a mistake that can happen to anyone, especially under pressure. So no point in discussing the personal oversight. So let me raise a different concern. This looks like an exploit for web browsers, where an average user (and most above average users) have no clue as to what's running unde…

> How do the end user protect themselves at this point? Especially the average user? Don't use unregulated financial products. The likelihood of a bank being hit by this isn't zero - but in most parts of the world they would be liable and the end user would be refunded. > How do you prevent supply chain compromises like this? Strictly audit your code. There's no magic answer here. Oh, I'm sure you can throw an LLM at…

So Node also has semver and also package-lock.json, but these are pretty cumbersome. These are a huge part of this.

Why a package with 10+ million weekly downloads can just be "updated" like this is beyond me. Have a waiting period. Make sure you have to be explicit. Use dates. Some of the packages hadn't been updated in 7 years and then we firehosed thousands of CI/CD jobs with them within minutes?

npm and most of these package manager should be getting some basic security measures like waiting periods. it would be nice if I could turn semver off to be honest and force folks to actually publish new packages. I'm always bummed when a 4 layer deep dependency just updates at 10PM EST because that's when the open source guy had time.

Packages used to break all the time, but I guess things kind of quieted down and people stopped using semvers as much. Like I think major packages like React don't generally have "somedepend" : "^1.0.0" but go with "1.0.0"

I think npm and the community knew this day was coming and just hopes it'll be fixed by tooling, but we need fundamental change in how packages are updated and verified. The idea that we need to "quickly" rollout a security fix with a minor patch is a good idea in theory, but in practice that doesn't really happen all that often. My audit returns all kinds of minor issues, but its rare that I need it...and if that's the case I'll probably do a direct update of my packages.

Package-lock.json was a nice bandaid, but it shouldn't have been the final solution IMHO. We need to reduce semver usage, have some concept of package age/importance, and npm needs a scanner that can detect obviously obfuscated code like this and at least put the package in quarantine. We could also use some hooks in npm so that developers could write easy to control scripts to not install newer packages etc.

Re: NPM debug and chalk packages compromised

#214

Post by niwtsol »

notmyjob wrote: post #184
rollcat wrote: post #94

Earlier quoted context omitted.

@everyone in the industry, everywhere: Urgency is poison. Please, please put a foot in the door whenever you see anyone trying to push this kind of sh*t on your users. Make one month's advance notice the golden standard. I see this pattern in scam mail (including physical) all the time: stamp an unreasonably short notice and expect the mark to panic. This scam works - and this is why legit companies that try this "in…

Agree, but this example wasn’t even that aggressive in its urgency and op said they were merely ticking things off the todo, not feeling alarmed by the urgency. The problem is email as it’s used currently. The solution is to not use email.

The email says accounts will start locking Sept 10th and it was sent Sept 8th - so a 48 hour urgency window or an account would be locked is urgency IMO

Re: NPM debug and chalk packages compromised

#215

Post by hackerindio »

junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

Hey, no problem, man. You do a lot for the community, and it's not all your fault. We learn from our mistakes. I was thinking of having a public fake profile to avoid this type of attack, but I'm not sure how it would work on the git tracking capabilities. Probably keeo it only internally for you&NPM ( the real one ) and have some fake ones open for public but not sure, just an obfuscated idea. Thanks for taking the responsibility and working in fixing ASAP. God bless you.

Re: NPM debug and chalk packages compromised

#216

Post by notmyjob »

zero_shift wrote: post #180
austin-cheney wrote: post #167

Earlier quoted context omitted.

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years. Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and sc…

> The responses vary but often take the form of reused cliches of which some don't even directly apply. "It has been tested by a 1000 people before me" "What if there is an upstream optimisation?" "I'm just here to focus on Business Problems™" "It reduces cognitive load" --- Whilst I think you are exaggerating, I do recognise this phenomenon. For me, it was during the pandemic when I had to train / support a lot of b…

Not sure about “agreeableness” but I can see group think and disagreeableness to anything that falls outside of the group think. Cargo cult coding isn’t a new thing but the demographic shift you note is real. But is that not just the commodification of programming labor?

Re: NPM debug and chalk packages compromised

#217

Post by IshKebab »

austin-cheney wrote: post #167
stathibus wrote: post #18

As an outsider to the npm ecosystem, reading this list of packages is astonishing. Why do js people import someone else's npm module for every little trivial thing?

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years. Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and sc…

Not my experience at all. It's more like a) JS devs view NPM packages as a mark of pride and so they try to make as many as possible (there are people proud of maintaining hundreds of packages, which is obviously dumb), and b) people are lazy and will take a ready-made solution if it's available, and c) there are a lot of JavaScript developers.

The main reasons you don't see this in other languages is they don't have so many developers, and their packaging ecosystems are generally waaay higher friction. Rust is just as easy, but way higher skill level. Python is... not awful but it's definitely still a pain to publish packages for. C++, yeah why even bother.

If Python ever official adopts uv and we get a nice `uv publish` command then you will absolutely see the same thing there.

Re: NPM debug and chalk packages compromised

#218

Post by joshmanders »

junon wrote: post #9

Hi, yep I got pwned. Sorry everyone, very embarrassing. More info: - https://github.com/chalk/chalk/issues/656 - https://github.com/debug-js/debug/issues/1005#issuecomment-3... Affected packages (at least the ones I know of): - ansi-styles@6.2.2 - debug@4.4.2 (appears to have been yanked as of 8 Sep 18:09 CEST) - chalk@5.6.1 - supports-color@10.2.1 - strip-ansi@7.1.1 - ansi-regex@6.2.1 - wrap-ansi@9.0.1 - color-conve…

Insanely well crafted phishing, godspeed man.

Re: NPM debug and chalk packages compromised

#219

Post by 1023bytes »

nodesocket wrote: post #13

This is terrifying. Reminder to store your crypto in a hardware based wallet like Ledger not browser based. Stay frosty when making transfers from exchanges.

If an exchange got compromised there's no way you would know you're sending to the attackers address

Re: NPM debug and chalk packages compromised

#220

Post by wewtyflakes »

nixosbestos wrote: post #96
nodesocket wrote: post #37

Earlier quoted context omitted.

Like you’ve never made a mistake before. Blatantly blaming the maintainer is unfair. They made a mistake, it happens.

No, I have never, ever responded to an explicit ask to reset the most important security feature of my accounts, without me initiating it, and I use a password manager (lol) so, no, I will never, ever encounter this problem. Because I care about my data, safety, and integrity, and my users'. There's literally no reason ever why I would or will do a 2FA reset. It does happen, yes, it's not terrifying.

Nobody cares if you, specifically, are this diligent. The terror is because unless _absolutely everyone_ who maintains NPM packages is this diligent, then we are all vulnerable. That sounds terrifying to me!
Post reply on HN