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

731–740 of 796 posts

Re: NPM debug and chalk packages compromised

#731

Post by hunter2_ »

mcjiggerlog wrote: post #177
hunter2_ wrote: post #60

Earlier quoted context omitted.

I agree, and this is arguably the best reason to use a password manager (with the next being lack of reuse which automatically occurs if you use generated passwords, and then the next being strength if you use generated passwords). I generally recommend Google's to any Android users, since it suggests your saved password not only based on domain in Chrome browser, but also based on registered appID for native apps, t…

I actually also received this phishing email, also read it while half-asleep after a 6 week break and clicked on it. Luckily I was saved by exactly this - no password suggestion made me double check the domain.

Nice. It's basically a TOFU system (unfortunately disguised).

Re: NPM debug and chalk packages compromised

#732

Post by _el1s7 »

bflesch wrote: post #114
DDerTyp wrote: post #52

One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list. It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one. This is a brilliant…

Can you attribute this technique to a specific group?

It's not a "group specific" technique.

This is smart, but not really unusual.

Re: NPM debug and chalk packages compromised

#733

Post by notmyjob »

naikrovek wrote: post #315
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 solution is to not use email. and use what? instant message? few things lack legitimacy more than an instant message asking you to do something. Links in email are much more of a problem than email itself. So tempting to click. It's right there, you don't have to dig through bookmarks, you don't have to remember anything, just click. A link is seductive. the actual solution is to avoid dependencies whenever pos…

Depends what you use it for. I don’t think email is a single thing in that regard. For example I’ve used it as a backup method for important files and also as 2 factor. Those are wholly different things that warrant different solutions. The majority of email volume is not person to person communication but part of some corporation/spammers/scammers business model who at best, like my bank, is using it to shift liability away from themselves onto consumers and at worst is attempting to defraud me of all I own. It’s still useful in business, maybe, but pretty sure teams/slack/… will win eventually.

Re: NPM debug and chalk packages compromised

#734

Post by junon »

vaylian wrote: post #632
SchemaLoad wrote: post #556

Earlier quoted context omitted.

I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished. I have to manually select the site to fill fairly often, especially inside apps where the password manager doesn't seem to match the app to the website password. Passkeys seem like the best solution here where you physically can not fall for a phishing attack.

> I feel like it's extremely common for the autofill to not work for various reasons even when you aren't being phished. This is how Troy Hunt got phished. He was already very tired after a long flight, but his internal alarm bells didn't ring loud enough, when the password manager didn't fill in the credentials. He was already used to autofill not always working.

This is why I haven't bothered with them (the browser extensions; I have used password managers for years and years) and thus why they weren't there to protect against the attack.

Re: NPM debug and chalk packages compromised

#735

Post by junon »

discomrobertul8 wrote: post #643
junon wrote: post #471

Earlier quoted context omitted.

I wrote it 10 years ago, I think before Node was v1, and forgot about it for a long time. This was back before we had spreads, classes, typescript, and had to use DOM arrays and other weird structures, and where `arguments` wasn't an array but an object. > (function() { return Array.isArray(arguments); })() false

Do you think it might be time to deprecate and then retire this package, given that the ecosystem has evolved? Sure, it'll mean downstream packages will need to update their reliance on `is-arrayish` and use some other means suited to their task, but perhaps that's positive design pressure?

Even if I sunset those packages, they'd still be downloaded and used in perpetuity, and certainly for many years afterward, even by popular packages, and even by such packages that have removed them in newer versions. Even if I had done this five years ago, I'd wager the scope of this attack would have been similar in size - maybe a billion less, but that's still a billion with a B, at which point I really wonder if it would have mattered as much.

I agree that `is-arrayish` is silly, but that's not really the problem that needs fixing, in my opinion. There's a general, cross-language package management culture that has permeated over the last 10-15 years that is susceptible to this exact problem. It's TOTP today (in my case), something else tomorrow, and it can come to a Package Manager Near You at any time - npm is just a ripe target because of how much it's used, and how concentrated the download counts are for some of its larger packages, especially given how CI has started to operate (re-downloading everything etc).

That's just my $0.02 on it though.

Re: NPM debug and chalk packages compromised

#736

Post by int_19h »

crabmusket wrote: post #441
palmfacehn wrote: post #189

Earlier quoted context omitted.

Things like this are good illustrations as to why many feel that the entire JS ecosystem is broken. Even if you have a standard lib included in a language, you wouldn't expect a bigger binary because of the standard lib. The JS solution is often more duct tape on top of a bad design. In this case tree shaking, which may or may not work as intended.

I agree with you, but I'd ask- what other language needs to distribute to an unknown runtime environment over the network? If it's the browser's job to implement the standard library, how do you ensure that all browsers do this in a compliant and timely fashion? And if not, how do you optimise code-on-demand delivery over the internet? I don't deny there are/could be solutions to this. But historically JS devs have w…

> how do you ensure that all browsers do this in a compliant and timely fashion?

The ecosystem somehow manages to figure this out for things like fancy CSS gradients...

Re: NPM debug and chalk packages compromised

#737

Post by jonquest »

goodpoint wrote: post #687
jonquest wrote: post #476

Earlier quoted context omitted.

Yes, the XZ attack affected Fedora nightly and Debian testing and unstable. Yes, it got caught before it made it into a stable distribution (this time). https://www.redhat.com/en/blog/understanding-red-hats-respon... https://lists.debian.org/debian-security-announce/2024/msg00...

So the attack was successfully stopped and you complain about it?

I’m not complaining, I’m pointing out facts. If the facts offend you, that’s your problem. Ignore them if you wish.

Re: NPM debug and chalk packages compromised

#738

Post by int_19h »

9dev wrote: post #448
palmfacehn wrote: post #223

Earlier quoted context omitted.

There's also the option of including that standard lib with the runtime.

And never ever be able to correct your past mistakes, because some sites might still be using them? The web platform is no .NET runtime you can just update.

Web browsers update far more often than .NET runtime, if anything. And .NET still supports a lot of deprecated stuff going all the way back to 1.0; so does Java (old-style collections, for example).

Also, JavaScript is a shining example of "never ever be able to correct your past mistakes" already, so it's not like this is something new for the web.

Re: NPM debug and chalk packages compromised

#739

Post by int_19h »

crabmusket wrote: post #443
palmfacehn wrote: post #223

Earlier quoted context omitted.

There's also the option of including that standard lib with the runtime.

That is exactly what happens today. JS has a standard library. It's just not evenly distributed.

JS standard library is missing very basic things like maps with value semantics for keys that aren't primitives.

Re: NPM debug and chalk packages compromised

#740

Post by johnisgood »

fn-mote wrote: post #466
dmitrygr wrote: post #404

Earlier quoted context omitted.

> don't we consider things like `brew` to be sufficiently low-risk, Like ... npm?

Nah… Everybody knows npm is a gaping security issue waiting to happen. Repeatedly. It’s convenient, so it’s popular. Many people also don’t vendor their own dependencies, which would slow down the spread at the price of not being instantly up to date.

Convenient, as in the barrier to entry is way too low. I am pretty much against it.
Post reply on HN