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

GitLab discovers widespread NPM supply chain attack

about.gitlab.com

Post reply on HN
Print view View original

241–250 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#241

Post by rkagerer »

Once upon a time I would download the source code of a library, unzip it, and personally vet the code before adding it to my project.

With some package managers these days I don't even know how to do that (and I'm not necessarily talking about Node, specifically). How do you figure out what the install process does to your computer, without becoming an expert on the manifest syntax? For those of us who care about what goes on under the hood, it is definitely not easier than the days of following well-formed (or even semi-formed) documentation by hand.

Re: GitLab discovers widespread NPM supply chain attack

#242

Post by rkagerer »

sigmoid10 wrote: post #141
qubex wrote: post #102

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “bre…

This is why you want containerisation or, even better, full virtualisation. Running programs built on node, python or any other ecosystem that makes installing tons of dependencies easy (and thus frustratingly common) on your main system where you keep any unrelated data is a surefire way to get compromised by the supply chain eventually. I don't even have the interpreters for python and js on my base system anymore…

Ok, but if you distrust the library so much it needs to go in a VM, what the hell are you doing shipping it to your customers?

Re: GitLab discovers widespread NPM supply chain attack

#244

Post by brabel »

lionkor wrote: post #134
brabel wrote: post #132

Earlier quoted context omitted.

Not a C expert but you’re using a dynamic array right on the stack, and then returning the duplicate of that. Shouldn’t that be Malloc’ed instead?? Is it safe to return the duplicate of a stack allocated array, wouldn’t the copy be heap allocated anyway? Not to mention it blows the stack and you get segmentation fault?

strdup allocates https://en.cppreference.com/w/c/experimental/dynamic/strdup

My point was that if you’re going to allocate anyway what was the point of allocating the original on the stack? You wouldn’t need the duplicate if you malloc that.

Re: GitLab discovers widespread NPM supply chain attack

#245

Post by ozgrakkurt »

hirsin wrote: post #26
morkalork wrote: post #24

Earlier quoted context omitted.

That would be easily defeated by a VPN. The inevitable evolution would be some kind of in-person attestation of identity backed up with some kind of insurance on the contributor's work, and, well you're converging on the employer-employee relationship then.

Yep, I saw the cat and mouse ending at ever increasingly invasive verifications involving more parties, that could ultimately still be worked around by a state actor. We already get asked for "block access from these country ip ranges please" as a security measure despite it being trivially bypassed, so it is easy to predict a useless but strong demand for blocking users based on their verified country.

This feels so true, all this surveillence/controlling seems like it will be a non issue for the dedicated hacker or criminal eventually and just a lost right for the regular person

Re: GitLab discovers widespread NPM supply chain attack

#246

Post by 1718627440 »

brabel wrote: post #244
lionkor wrote: post #134

Earlier quoted context omitted.

strdup allocates https://en.cppreference.com/w/c/experimental/dynamic/strdup

My point was that if you’re going to allocate anyway what was the point of allocating the original on the stack? You wouldn’t need the duplicate if you malloc that.

Yes, that is right. The only reason I did it this way was, because I wanted to demonstrate a naive implementation, I wouldn't commit that, but I wouldn't commit leftpad at all.

Allocating on the stack is pretty cheap, it's only a single instruction to move the stack pointer. The compiler is likely to optimize it away completely. When doing more complicated things, where you don't build the string linearly allocating on the stack first can be likely cheaper, since the stack memory is likely in cache, but a new allocation isn't. It can also make the code easier, since you can first do random stuff on the stack and then allocate on the heap once the string is complete and you know its final size.

Re: GitLab discovers widespread NPM supply chain attack

#247

Post by nottorp »

AmbroseBierce wrote: post #216
nottorp wrote: post #101

Earlier quoted context omitted.

Or it's worse, because there's a good bunch of devs that don't trust MS by default?

Even the most hardcore GNU supporters don't think Microsoft would add a supply chain attack to such initiative, or that their software security is worse than the average NPM (popular) package maintainer.

Just the lock in and telemetry are dangerous :)

And they're company policy as opposed to honest mistakes like security vulns.

Re: GitLab discovers widespread NPM supply chain attack

#248

Post by tedivm »

SAI_Peregrinus wrote: post #197
tedivm wrote: post #173

Earlier quoted context omitted.

This advice leaves you vulnerable to log4j style vulnerabilities that get discovered though. The answer is a balance. Use Dependabot to keep dependencies up to date, but configure a dependency cooldown so you don't end up installing anything too new. A seven day cooldown would keep you from being vulnerable to these types of attacks.

Cooldowns only work if enough people don't use cooldowns (or don't use cooldowns longer than yours) for attacks to get noticed.

That may have been true two years ago, but now you have groups like Wiz doing scans and looking for these types of attacks. You don't have to wait for someone to get their shit destroyed to notice.

Re: GitLab discovers widespread NPM supply chain attack

#249

Post by queenkjuul »

akdev1l wrote: post #152
febusravenga wrote: post #75

Earlier quoted context omitted.

this, this, this All our tokens should be in is protected keychain and there are no proper cross-platform solutions for this. All gclouds, was aww sdks, gh and other tools just store them in dotfile. And worst thing, afaik there is no way do do it correctly in MacOS for example. I'd like to be corrected though.

For what it’s worth, the recommended way of getting credentials for AWS would be either: 1. Piggyback of your existing auth infra (eg: ActiveDirectory or whatever you already have going on for user auth) 2. Failing that use identity center to create user auth in AWS itself Either way means that your machine gets temporary credentials only Alternatively, we could write an AWS CLI helper to store the stuff into the key…

Snap works with CLI tools. But underneath that, isn't it AppArmor and namespaces? (I don't really know. I'm getting the impression flatpak-style process isolation is possible just not widely adopted)

Re: GitLab discovers widespread NPM supply chain attack

#250

Post by bakkoting »

jazzypants wrote: post #237
bakkoting wrote: post #208

Earlier quoted context omitted.

Very few packages published on npm include polyfills, especially packages you'd use when doing local scripting.

I'm sorry, but this is just incorrect. Have you ever heard of ljharb[0]? The NPM ecosystem is rife with polyfills[1]. I don't know how you can make a distinction on which libraries would be used for "local scripting" as I don't think many library authors make that distinction. [0] - TC39 member who is self-described as "obsessed with backwards compatibility": https://github.com/ljharb [1] - Here's one of many article…

Yes. I'm on TC39 as well, and I've talked to Jordan about this topic.

It's true that there are a few people who publish packages on npm including polyfills, Jordan among them. But these are a very small fraction of all packages on npm, and none of the compromised packages were polyfills. Also, he cares about backwards compatibility _with old versions of node_; the fact that JavaScript was originally a web language, as the grandparent comment says, is completely irrelevant to the inclusion of those specific polyfills.

Polyfills are just completely irrelevant to this discussion.

Post reply on HN