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

131–140 of 263 posts

Re: GitLab discovers widespread NPM supply chain attack

#131

Post by akshitgaur2005 »

mcny wrote: post #88
didntcheck wrote: post #85

Earlier quoted context omitted.

That's true, but the same may already be true of your browser's cookie file. I believe Chrome on MacOS and Windows (unsure about Linux) now does use OS features to prevent it being read from other executables, but Firefox doesn't (yet) But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than endlessly updating a patchy blacklist

> But protecting specific directories is just whack-a-mole. The real fix is to properly sandbox code - an access whitelist rather than blacklist I believe Wayland (don't quote me on this because I know exactly zero technical details) as opposed to x is a big step in this direction. Correct me if I am wrong but I believe this effort alone has been ongoing for a decade. A proper sandbox will take longer and risks being…

Maybe I am missing something but how and why would a display protocol have anything to do with file access model??

Re: GitLab discovers widespread NPM supply chain attack

#132

Post by brabel »

1718627440 wrote: post #114
TheTxT wrote: post #61

Earlier quoted context omitted.

But how do you left pad a string?

char * left_pad (const char * string, unsigned int pad) { char tmp[strlen (string)+pad+1]; memset (tmp, ' ', pad); strcpy (tmp+pad, string); return strdup (tmp); } Doesn't sound too hard in my opinion. This only works for strings, that fit on the stack, so if you want to make it robust, you should check for the string size. It (like everything in C) can of course fail. Also it is a quite naive implementation, since i…

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?

Re: GitLab discovers widespread NPM supply chain attack

#133

Post by lionkor »

Ferret7446 wrote: post #69
thepasswordapp wrote: post #31

The credential harvesting aspect is what concerns me most for the average developer. If you've ever run `npm install` on an affected package, your environment variables, .npmrc tokens, and potentially other cached credentials may have been exfiltrated. The action item for anyone potentially affected: rotate your npm tokens, GitHub PATs, and any API keys that were in environment variables. And if you're like most deve…

> if you're like most developers and reused any of those passwords elsewhere Is this true? God I hope not, if developers don't even follow basic security practices then all hope is lost. I'd assume this is stating the obvious, but storing credentials in environment variables or files is a big no-no. Use a security key or at the very least an encrypted file, and never reuse any credential for anything.

I think so. I know too many developers who cannot be bothered to have a password-manager, beyond the chrome/firefox default one. Anything else, and even those, are usually "the standard 2-3 passwords" they use.

Re: GitLab discovers widespread NPM supply chain attack

#134

Post by lionkor »

brabel wrote: post #132
1718627440 wrote: post #114

Earlier quoted context omitted.

char * left_pad (const char * string, unsigned int pad) { char tmp[strlen (string)+pad+1]; memset (tmp, ' ', pad); strcpy (tmp+pad, string); return strdup (tmp); } Doesn't sound too hard in my opinion. This only works for strings, that fit on the stack, so if you want to make it robust, you should check for the string size. It (like everything in C) can of course fail. Also it is a quite naive implementation, since i…

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

Re: GitLab discovers widespread NPM supply chain attack

#135

Post by lionkor »

Incipient wrote: post #7

Surely in this day and age we can fairly trivially find out these come from the usual suspects - China, Russia, Iran, etc. Being in such a digital age, where our economies are built on this tech...is this not effectively (economic) warfare? Why are so many governments blase about it?

I wonder that, too. Surely, this is a fantastic opportunity to claim that it comes from whoever is declared evil right now, and force a harder us-vs-them mindset. If people don't have a clearly defined "evil bad guy" that is responsible for everything bad, how will you get teenagers to die for your country in war?

Or, in other words; maybe the nature of humans and the inherent pressure of our society to perform, to be rich, to be successful, drives people to do bad things without any state actor behind it?

Re: GitLab discovers widespread NPM supply chain attack

#136

Post by 1718627440 »

brabel wrote: post #132
1718627440 wrote: post #114

Earlier quoted context omitted.

char * left_pad (const char * string, unsigned int pad) { char tmp[strlen (string)+pad+1]; memset (tmp, ' ', pad); strcpy (tmp+pad, string); return strdup (tmp); } Doesn't sound too hard in my opinion. This only works for strings, that fit on the stack, so if you want to make it robust, you should check for the string size. It (like everything in C) can of course fail. Also it is a quite naive implementation, since i…

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?

> and then returning the duplicate of that. Shouldn’t that be Malloc’ed instead??

Like the sibling already wrote, that's what strdup does.

> Is it safe to return the duplicate of a stack allocated

Yeah sure, it's a copy.

> wouldn’t the copy be heap allocated anyway?

Yes. I wouldn't commit it like that, it is a naive implementation. But honestly I wouldn't commit leftpad at all, it doesn't sound like a sensible abstraction boundary to me.

> Not to mention it blows the stack and you get segmentation fault?

Yes and I already mentioned that in my comment.

---

> dynamic array right on the stack

Nitpick: It's a variable length array and it is auto allocated. Dynamic allocation refers to the heap or something similar, not already done by the compiler.

Re: GitLab discovers widespread NPM supply chain attack

#137

Post by 1718627440 »

L-four wrote: post #115
mcny wrote: post #86

Earlier quoted context omitted.

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices. I feel like we are barking up the wrong tree here. The plain text token…

I think the correct solution is to use a keyring. On Linux there's gnome keyring and last time I worked on a IOS app there was something similar. This does mean entering your keyring password a lot. https://en.wikipedia.org/wiki/GNOME_Keyring

> This does mean entering your keyring password a lot.

Not when you put that keyrings password into the user keyring. I think it is also cached by default.

Re: GitLab discovers widespread NPM supply chain attack

#138

Post by flir »

mcny wrote: post #86
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.

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices. I feel like we are barking up the wrong tree here. The plain text token…

It might be possible to lash up a cross-plaform solution with KeePassXC. It's got an API that can be accessed from the command line (chezmoi uses it to add secrets to dotfiles). Yes, you'd be authenticating every time you need a token but that might not be too much of a burden if you spend most of your time on a machine with a fingerprint scanner.

otoh I wouldn't do it, because I don't believe I could implement it securely.

Re: GitLab discovers widespread NPM supply chain attack

#139

Post by gerardnico »

sakisv wrote: post #123
mcny wrote: post #86

Earlier quoted context omitted.

What is a proper solution for this? I don't imagine gpg can help if you encrypt it but decrypt it when you login to gnome, right? However, it would be too much of a hassle to have to authenticate each time you need a token. I imagine macOS people have access to the secure enclave using touch ID but then even that is not available on all devices. I feel like we are barking up the wrong tree here. The plain text token…

The way I solve the plain text problem is through a combination of direnv[1] and pass[2]. For a given project, I have a `./creds` directory which is managed with pass and it contains all the access tokens and api keys that are relevant for that project, one per file, for example, `./creds/cloudflare/api_token`. Pass encrypts all these files via gpg, for which I use a key stored on a Yubikey. Next to the `./creds` dir…

You can even go further and delete all your secrets from your env by creating wrapper scripts

Example : https://github.com/combostrap/devfiles/blob/main/dev-scripts...

It’s not completely full proof but at least gpg asks my passphrase only when I run the script

Re: GitLab discovers widespread NPM supply chain attack

#140

Post by hsbauauvhabzb »

mikkupikku wrote: post #126

> "This creates a dangerous scenario. If GitHub mass-deletes the malware's repositories or npm bulk-revokes compromised tokens, thousands of infected systems could simultaneously destroy user data." Pop quiz, hot shot! A terrorist is holding user data hostage, got enough malware strapped to his chest to blow a data center in half. Now what do you do? Shoot the hostage.

The hostage naively walked past all the police and into the data centre, and you’re shooing them in the leg. They’ll probably survive, but they knowingly or incompetently made their choice. Sucks to be them.
Post reply on HN