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

DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

github.com

Post reply on HN
Print view View original

211–220 of 296 posts

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#211

Post by sunaookami »

IshKebab wrote: post #44
diggan wrote: post #12

So far, it seems to be a bog-standard phishing email, with not much novelty or sophistication, seems the people running the operation got very lucky with their victims though. I'm starting to think we haven't even seen the full scope of it yet, two authors confirmed as compromised, must be 10+ out there we haven't heard of yet?

Probably the differentiating factor here is that the phishing message was very plausible. Normally they're full of spelling mistakes and unprofessional grammar. The domain was also plausible. I think where they got lucky is > In hindsight, the fact that his browser did not auto-complete the login should have been a red flag. A huge red flag. I wonder if browsers should actually detect if you're putting login details…

Nothing is plausible about this phishing mail - writing "update your password now" would be understandable but "update your 2FA now"? Never EVER seen this on any real site and it doesn't make sense (rotating passwords doesn't make sense either but not everyone got the memo).

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#212

Post by 0xbadcafebee »

smw wrote: post #180
0xbadcafebee wrote: post #126

At least third major compromise in two weeks. (last comment: https://news.ycombinator.com/item?id=45172225 ) (before that: https://news.ycombinator.com/item?id=45039764 ) Forget about phishing, it's a red herring. The actual solution to this is code signing and artifact signing. You keep a private key on your local machine. You sign your code and artifacts with it. You push them. The packages are verified by the end-…

"2) mandatory 2FA (with the option for things like passkeys with hardware tokens)." No, with the _requirement_ for passkeys or hardware tokens!

They don't work everywhere, and when they do work they're not a panacea. It's like host-based security: if you get past this one barrier... what, everything is completely pwnd? You need defense in depth. That means the authentication factor(s) must not be the final word in security. So not using a passkey or hardware token shouldn't be a death knell.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#213

Post by koakuma-chan »

SOLAR_FIELDS wrote: post #210
koakuma-chan wrote: post #205

Earlier quoted context omitted.

Also USB A is not even square, it's a rectangle

Point still stands. Maybe it’s 5 if we are being charitable. Do you also call skillets “flat pan thing I cook with”?

You mean frying pan?

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#214

Post by 0xbadcafebee »

throwaway127482 wrote: post #143
vitonsky wrote: post #137

Just for context. DuckDB team is consistently ignores any security practices. The single one method how to install DuckDB on laptop is to run `curl https://install.duckdb.org | sh` I've requested to deliver CLI as standard package, they have ignored it. Here is the thread https://github.com/duckdb/duckdb/issues/17091 As you can see that it isn't single slip due to "human factor", but DuckDB management consistently pu…

Genuine question: why is `curl https://trusted-site.com | sh` a security risk? Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right? Like, I don't see how it's different than going to their website, copying their recommended command to install via a standard repo, then pasting that command into your shell. Either way, you…

> Fundamentally, doesn't the security depend entirely on whether https is working properly? Even the standard package repos are relying on https right?

They should only need http. You don't need https at all if your package is signed. The package/installer/app/etc could come from anywhere, modified by anyone, at any level. But if it's not signed by the dev's private key (which only exists on their laptop [or hardware token], protected by a password/key manager), it's invalid. This avoids the hundred different exploits between the dev and the user.

What's actually crazy about this is, if you're already making the user do a copy and paste, it doesn't have to be one line. Compare that line above, to:

  (set -eu; tmpf="$(mktemp)"; [ -w "$tmpf" ] &&
  curl https://install.duckdb.org/ -o "$tmpf" &&
  echo "d5d91c69a874ef99c30cf36654f623ed9c423ed0e210dca229744ce4d3b273d0 *$tmpf" | sha256sum -c - &&
  bash "$tmpf")
All you have to do is copy and paste that snippet, and the same thing will happen as the one-liner, except it will only work if the sha256sum is valid. Now this isn't perfect of course, we should be using artifacts signed by a private key. But it's better than just praying.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#215

Post by SahAssar »

greatgib wrote: post #202

What is funny is again how many "young developers" had fun at old timers package managers like Debian being so slow to release new versions of packages. But never ever anyone was rooted because of malware that was snuck into an official .deb package. That was the concept of "stable" in the good old time, when software was really an "engineering" field.

> But never ever anyone was rooted because of malware that was snuck into an official .deb package.

We got pretty close with the whole XZ thing. And people generated predictable keys due to a flaw in a debian patch to openssl.

This stuff is hard and I'm not saying that npm is doing well but seems like no large ecosystem is doing exceptionally well either.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#216

Post by frizlab »

cesarb wrote: post #177
frizlab wrote: post #108

Earlier quoted context omitted.

I take the downvote but I’d like to know why? Passkeys are effectively and objectively a better security solution than password+2FA. Among other things, they are completely unfishable.

> Among other things, they are completely unfishable. From what I've heard, they're also unbackupable, and tied to the ecosystem used to create them (so if you started with an Apple desktop, you can't later migrate the passkeys to a Windows desktop, you have to go to every single site you've ever used and create new ones).

That’s not true anymore; you can migrate passkeys to another password manager now.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#218

Post by OkayPhysicist »

InsideOutSanta wrote: post #166
chrisweekly wrote: post #131

Earlier quoted context omitted.

Re: "npmjs dot help", way too many companies use random domains -- effectively training their users to fall for phishing attacks.

This exactly. It's actually wild how much valid emails can look like phishing emails, and how confusing it is that companies use different domains for critical things. One example that always annoys me is that the website listing all of Proton's apps isn't at an address you'd expect, like apps.proton.me. It's at protonapps.com. Just... why? Why would you train your users to download apps from domains other than your…

I can answer why this is at the company I work at right now:

It's a PITA to coordinate between teams, and my team doesn't control the main domain. If I wanted my team's application to run on the parent domain, I would have to negotiate with the crayon eaters in IT to make a subdomain, point it at whatever server, and then if I want any other changes to be made, I'd have to schedule a followup meeting, which will generate more meetings, etc.

If I want to make any changes to the mycompany.othertld domain, I can just do it, with no approval from anyone.

Re: DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

#220

Post by 3np »

mdaniel wrote: post #141
HatchedLake721 wrote: post #130

Earlier quoted context omitted.

Don’t auto install latest versions, pick a version up to a patch and use package-lock.json

That's only half the story, as I learned yesterday https://news.ycombinator.com/item?id=45172213 > since even with lock files one must change the verb given to npm/yarn to have them honor the lock file So, regrettably, we're back to "train users" and all the pitfalls that entails

More importantly, avoid yarn[0] if you have a choice. They do not have a security posture fitting for 2025. There's way too much assumptions like "helpful" "magic" guessing/inferring what the user "actually wants" to "make things just work". See also: corepack.

[0]: legacy 1.x projects aside

Post reply on HN