Ironically, the hardest part might be to meet the actual requirements to run the packages, since python dependencies have been so braindead lately
Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
161–170 of 196 posts
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#162Earlier quoted context omitted.
People are ramming tons of code into places without ever looking at it, it would follow that supply chain attacks would increase thusly.
Yeah, and ultimately no body cares. Everyone assumes it’s just some process miss, and we need to add another step to the process and move on. Fuck ups that would have killed the credibility of projects 10 years ago are now treated as “eeh what are you gonna do. Sometimes you ship malware. Will look into it”
Personally I was sus of Tailscale, but stopped even pondering it after they got an RCE.
Same with npm and large dependency trees with 10.5 line libraries of low quality.
Lighting always seemed to be the leftpad of PyTorch. It was basically a replacement for a for loop and a couple of backward/step calls. I'm sure now it grew to replace a few more lines of code though. Like maybe a 100.
If you want to look for a coming disaster, look no further than HuggingFace libraries that for some reason quite a lot of projects use these days, especially transformers package. Sadly even vllm depends on it.
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#163This might just be the frequency illusion at play, but there seem to have been a number of high-profile supply chain attacks of late in major packages. There are several articles on the first few pages of HN right now with different cases. Looking back ten years to `left-pad`, are there more successful attacks now than ever? I would suspect so, and surely the value of a successful attack has also increased, so are we…
The reason is that auto-updates and CI tools have reached a critical saturation and everybody uses them. Years ago, `npm install` would have been more likely to be run manually, and only if something in the build breaks - which means once in a blue moon. Supply chain attacks depend on people (or more likely, pipelines) mindlessly auto-updating packages as soon as they are released.
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#164so i'm guessing something like this would be caught by (open\|little)snitch. the raw c2 post coming from the python process would definitely be a red herring, but i wonder how obvious the git/github activity would be. it would seem kinda weird if it came from the python process itself, but if it were just git or gh in a subprocess, it would possibly look totally normal and even have a temporary allow rule in place...
maybe it's time for a nextgen opensnitch where the rules table is replaced by an active agent that watches connections and the process table?
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#165It's crazy to me how just a year or so after xz people were willing to say "sure I'll take this giant black box so unauditable that even it's creators don't really know what's in it and run all my data through it"
I'm guessing it ultimately comes down to the legal / financial / career incentives. My impression is that the market currently rewards visible software functionality with little concern for invisible risk. If we flipped the script, and investors were personally, criminally, and civilly liable for computer breaches, I imagine this problem would disappear almost overnight.
I'm at a defense contractor so the whole scene is alien to me. I don't really even get the desire to produce code more quickly since for us client verification and approval is always the slow part. Producing software more quickly would just make that problem worse.
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#166Earlier quoted context omitted.
What filter? You say you rely on CC to suggest software to install from the internet, and then you install it. I haven't heard anyone suggest CC or any LLM as a "filter" for "is this package safe right now", and it seems like a very bad heuristic to me, not only, but also for the reason you gave.
Well, people weren't checking CVEs before pip install before CC either, CC just scaled the habit to a larger audience at a faster cadence. The blast radius for day-zero compromises is what changed.
How has the blast radius changed though? The vibecoders that weren't developers before? If someone switched from pip installing themselves to having Claude do it, I don't see how that increased the blast radius.
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#167just to clarify it's not PyTorch, it's the library for this Lightning AI company?
Oh shit I had assumed PyTorch Lightning was affiliated with PyTorch. Not a great name for an unaffiliated third party thing.
It's standard naming if you write a plugin for something to do `{main-package}-{sub-package}` as the naming convention. `django-rest-framework` isn't an official Django project, but it's part of the Django ecosystem. This looks like "running PyTorch with our added stuff to make your life easier" so this naming convention isn't out of the norm.
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#168Earlier quoted context omitted.
Nope. Those on pinned versions don't get the malware. You would have to publish the infected package first to infect others who haven't pinned their dependencies. With a simple pip install -U, and if the dependency is not pinned, then they will get the vulnerable version.
I think it was a jab at the statement "if I pin the dep, I am safe". How do you know your current code is not compromised? No one reads all the code they run, anyway.
There is always a risk that at the time that you pinned, the code was already compromised, but it lowers your attack surface to pin. As long as you've pinned while the code was not compromised, then someone changing the package for an already pinned version will fail the install because hash check fails.
It's "if I pin the dep, I know that someone won't compromise the package repo and the next time I install 2.6.3 I can be sure that the same package is getting downloaded and installed."
This specific risk isn't just not having things version pinned. It's not having a hash of the package to check against to make sure you're getting the same package every time.
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#169[flagged]
Re: Shai-Hulud Themed Malware Found in the PyTorch Lightning AI Training Library
#170Disclaimer: I've never used pytorch and I also know nothing about software security practices.
But I don't see a scenario where pytorch needs network access. It seems wrong that at any level within the codebase I can import any module and use its API.
I think there need to be additional import restrictions or static analysis.
This also seems like languages do not have the right abstractions to talk about this stuff. As a comparison, I like how in rust I can look at the function signature and see the mutability and lifetimes of everything without understanding any of the code underneath.
I feel there needs to be something similar here with dependencies. A dev should be able to audit all their dependencies easily and see "oh dep X uses eval()" or network access, etc without looking at any underlying code.
Mobile apps enforce permissions. Shouldn't a dev be able to whitelist certain functionality and not take everything including the kitchen sink.