Microsoft warns enterprises of new 'dependency confusion' attack technique
-
New "dependency confusion" technique, also known as a "substitution attack," allows threat actors to sneak malicious code inside private code repositories by registering internal library names on public package indexes.
You mean downloading random blobs of code from random developers might be a bad idea?
-
New "dependency confusion" technique, also known as a "substitution attack," allows threat actors to sneak malicious code inside private code repositories by registering internal library names on public package indexes.
You mean downloading random blobs of code from random developers might be a bad idea?
Kent Sharkey wrote:
You mean downloading random blobs of code from random developers might be a bad idea?
Joking aside, yes, this is a bad idea. Yes, I know it's how more and more languages and ecosystems work. It's still a really bad idea. I'm learning about TypeScript at the moment via the book 'Learn TypeScript 3 by Building Web Applications'. It seems to me like a good introduction to TypeScript. It begins by describing how to set up a dev environment to match the author's one. Installing one or two packages in Node (I forget which ones now) pulls in some unbelievable number of other packages. (If you really want to know I'll get the names and numbers). This is absurd. I don't care that it's normal now. It's still absurd. It's dangerous, it's not properly maintainable (by which I mean that the coder doesn't really know what his codebase is), it's a mess. Back in the 90s, componentised code was seen as a future way forward, although the components were expected to be runtime consumer components that users could purchase and plug together. This didn't quite work out but now we've got dev components on a level that no one expected. It just evolved. And it's dangerous. There has to be a way forward from this. There's a lot of money to be made by someone who finds a way to catalogue and audit it all, moving it from what amounts to random code generation to actual, traceable, properly maintainable code.
-
Kent Sharkey wrote:
You mean downloading random blobs of code from random developers might be a bad idea?
Joking aside, yes, this is a bad idea. Yes, I know it's how more and more languages and ecosystems work. It's still a really bad idea. I'm learning about TypeScript at the moment via the book 'Learn TypeScript 3 by Building Web Applications'. It seems to me like a good introduction to TypeScript. It begins by describing how to set up a dev environment to match the author's one. Installing one or two packages in Node (I forget which ones now) pulls in some unbelievable number of other packages. (If you really want to know I'll get the names and numbers). This is absurd. I don't care that it's normal now. It's still absurd. It's dangerous, it's not properly maintainable (by which I mean that the coder doesn't really know what his codebase is), it's a mess. Back in the 90s, componentised code was seen as a future way forward, although the components were expected to be runtime consumer components that users could purchase and plug together. This didn't quite work out but now we've got dev components on a level that no one expected. It just evolved. And it's dangerous. There has to be a way forward from this. There's a lot of money to be made by someone who finds a way to catalogue and audit it all, moving it from what amounts to random code generation to actual, traceable, properly maintainable code.
Thank you. I was 3/4 convinced that people would be telling me I was an idiot for complaining about npm/winget/gem/the-rest. I'm glad to know I'm not the only one that this gives indigestion to. Especially after the "leftpad debacle[^]", I'd have hoped that people would step back from this process, not lean into it further. :((
TTFN - Kent
-
New "dependency confusion" technique, also known as a "substitution attack," allows threat actors to sneak malicious code inside private code repositories by registering internal library names on public package indexes.
You mean downloading random blobs of code from random developers might be a bad idea?
Of course, the real problem here is that you can be bitten by this even if you have no intention of downloading random blobs of code from random developers. You could just be trying to consume packages from your responsibly-curated private Azure Artifacts repo (for example), and this attack can surreptitiously insert random code because the package manager (for some stupid reason) prioritizes random public packages from an upstream source over your internal ones unless you take ridiculous measures to prevent it.
-
Thank you. I was 3/4 convinced that people would be telling me I was an idiot for complaining about npm/winget/gem/the-rest. I'm glad to know I'm not the only one that this gives indigestion to. Especially after the "leftpad debacle[^]", I'd have hoped that people would step back from this process, not lean into it further. :((
TTFN - Kent
Yes, I was thinking of the leftpad thing. It's amazing that the issue is not more common. Perhaps it is more common but pure deletions are way less common than insertion of (silent) malicious code. Problem is, we just don't know for sure.
-
Thank you. I was 3/4 convinced that people would be telling me I was an idiot for complaining about npm/winget/gem/the-rest. I'm glad to know I'm not the only one that this gives indigestion to. Especially after the "leftpad debacle[^]", I'd have hoped that people would step back from this process, not lean into it further. :((
TTFN - Kent
Kent Sharkey wrote:
I was 3/4 convinced that people would be telling me I was an idiot for complaining about npm/winget/gem/the-rest. I'm glad to know I'm not the only one that this gives indigestion to.
No you are not alone in this.
Quartz article end:
Mike Roberts, from Kik, said in an interview that he regretted not reaching out to Koçulu himself in the first place. ”From my perspective,” he said, “open-source, the community, is about helping each other out.”
First step: a lawyer asking Second step: a lawyer threatening Third step: a lawyer trying to buy Fourth Step: a lawyer threatening even harder but to someone else Fifth Step: Screwing the little private person everything blows up A manager of the triggering company says "he regrets not reaching out in the first time" ??? really? :omg: :omg: :omg: :wtf: :wtf: :wtf: C'mon... we are already old enough to now that this is utterly bullsh1t and dictated by the PR to try to give a "not do evil" impression
NPM:
“Un-un-publishing is an unprecedented action that we’re taking given the severity and widespread nature of breakage, and isn’t done lightly,” This action puts the wider interests of the community of npm users at odds with the wishes of one author; we picked the needs of the many.”
After putting the interests of a company over the copyright of one author that was there first, that surprisingly doesn't have the resources or the desire to have to fight for it. They should both get sued for being assh... and npm should be forced to recompile everything repairing the mess without overrunning the author's right to do what he wants with his code / package.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.