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

241–250 of 796 posts

Re: NPM debug and chalk packages compromised

#241

Post by 9dev »

mewpmewp2 wrote: post #146
9dev wrote: post #124

Earlier quoted context omitted.

Irritatingly, this doesn't turn up anything, despite having a theoretically-compromised project as per the package-lock.json… At least on my end

What do you mean irritatingly? Do you mean that you think 'grep -r "_0x112fa8"' is not enough or are you irritated that npm audit is flagging as if it was compromised?

I'm irritated because I expected to find at least one compromised file, but there were none. It may be, though, that we only use the affected packages as transitive development dependencies, in which case they are not installed locally. But a sliver of doubt remains that I missed something.

Re: NPM debug and chalk packages compromised

#242

Post by hnquestion10987 »

I'm a little confused after reading everything. I have an Expo app and if I run `npm audit`, I get the notification about `simple-swizzle`.

The GitHub page (https://github.com/advisories/GHSA-hfm8-9jrf-7g9w) says to treat the computer as compromised. What does this mean? Do I have to do a full reset to be sure? Should I avoid running the app until the version is updated?

Re: NPM debug and chalk packages compromised

#243

Post by timsh »

joaomoreno wrote: post #129

From sindresorhus: You can run the following to check if you have the malware in your dependency tree: `rg -u --max-columns=80 _0x112fa8` Requires ripgrep: `brew install rg` https://github.com/chalk/chalk/issues/656#issuecomment-32668...

If it produces no output, does that mean that there's no code that could act in the future? I first acted out of nerves and deleted the whole node-modules and package.lock in a couple of freshly opened Astro projects, curious if I should considered my web surfing to still be potentially malicious

Re: NPM debug and chalk packages compromised

#244

Post by NoahZuniga »

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…

One thing I've been thinking of is to restrict global access to packages. Something like ansi-styles doesn't need access to the crypto global, or to the DOM, or make web requests, etc. So if you can sandbox individual libraries, you can decrease the attack surface a lot.

You could imagine that a compromised pad-left package could read the contents of all password inputs on the page and send it to an attacker server, but if you don't let that package access the document, or send web requests, you can avoid this compromise.

Re: NPM debug and chalk packages compromised

#245

Post by 9dev »

parliament32 wrote: post #190
a022311 wrote: post #169

After all these incidents, I still can't understand why package registries don't require cryptographic signatures on every package. It introduces a bit more friction (developers downloading CI artifacts and manually signing and uploading them), but it prevents most security incidents. Of course, this can fail if it's automated by some CI/CD system, as those are apparently easily compromised.

Real registries do[1], npm is just amateur-hour which is why its usage is typically forbidden in enterprise contexts. [1] https://www.debian.org/doc/manuals/securing-debian-manual/de...

In all fairness—npm belongs to GitHub, which belongs to Microsoft. Amateur-hour is both not a valid excuse anymore, and also a boring explanation. GitHub is going to great lengths to enable SLSA attestations for secure tool chains; there must be systemic issues in the JS ecosystem that make an implementation of proper attestations infeasible right now, everything else wouldn't really make sense.

So if we're discussing anything here, why not what this reason is, instead of everyone praising their favourite package registry?

Re: NPM debug and chalk packages compromised

#246

Post by 33a »

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…

We also caught this right away at Socket,

https://socket.dev/blog/npm-author-qix-compromised-in-major-...

While it sucks that this happened, the good thing is that the ecosystem mobilized quickly. I think these sorts of incidents really show why package scanning is essential for securing open source package repositories.

Re: NPM debug and chalk packages compromised

#247

Post by [deleted] »

niwtsol wrote: post #214
notmyjob wrote: post #184

Earlier quoted context omitted.

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

[deleted]

Re: NPM debug and chalk packages compromised

#248

Post by dns_snek »

littlecranky67 wrote: post #22
andrewmcwatters wrote: post #15

@junon, if it makes you feel any better, I once had a Chinese hacking group target my router and hijack my DNS configuration specifically to make "amazon.com" point to 1:1 replica of the site just to steal my Amazon credentials. There was no way to quickly visualize that the site was fake, because it was in fact, "actually" amazon.com. Phishing sucks. Sorry to read about this. Edit: To other readers, yes, the exploit…

How did they get a valid ssl cert though?

Before HSTS you didn't need a valid certificate. When you typed "amazon.com" in the address bar your browser would first connect to the server unencrypted on port 80 which would then redirect you to the HTTPS address.

If someone hijacked your DNS, they could direct your browser to connect to their web server instead which served a phishing site on port 80 and never redirected you, thus never ran into the certificate issue. That's part of the reason why browsers started warning users when they're connecting to a website without HTTPS.

Re: NPM debug and chalk packages compromised

#249

Post by samhh »

anticristi wrote: post #116

This is really scary. It could have totally happened to me too. How can we design security which works even when people are tired or stressed? Once upon a time, I used a software called passwordmaker. Essentially, it computed a password like hash(domain+username+master password). Genius idea, but it was a nightmare to use. Why? Because amazon.se and amazon.com share the same username/password database. Similarly, the…

Passkeys already solve for this, we just have to get past the FUD.

Re: NPM debug and chalk packages compromised

#250

Post by aaronharnly »

withinboredom wrote: post #192
diggan wrote: post #178

Earlier quoted context omitted.

> This isn’t exactly true. My password manager fails to recognise the domain I’m on, all the time. I have to go search for it and then copy/paste it in. I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :) > That being said, if you’re making login pages I think we're doomed on this front already. My previo…

> I'd probably go looking for a new password manager if it fails to do one of the basic features they exist for, copy-pasting passwords defeats a lot of the purpose :) This isn’t the fault of the password managers themselves, but devs not putting the right metadata on their login forms, or havo the password field show only after putting in the email address, causing the password input to fail to be filled, etc.

or switching to some generic-sounding domain during login
Post reply on HN