Interesting world we live in. I just finished teaching an advanced data science course for one of my clients. I found my self constantly twitching everytime I said "when I write code..." I'm barely writing code at all these days. But I created $100k worth of code just yesterday recreating a poorly maintained (and poor ux) library. Tested and uploaded to pypi in 90 minutes. A lot of the conversation in my course was d…
My minute-by-minute response to the LiteLLM malware attack
71–80 of 194 posts
Re: My minute-by-minute response to the LiteLLM malware attack
#72Earlier quoted context omitted.
The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
I realize this is controversial (and many Python folks would claim anti ethical). But I keep wondering if requiring a small payment for registering and updating packages would help. The money could go to maintaining pypix as well as automated AI analysis. Folks who really couldn't afford it could apply for sponsorship.
If pypi charges money, python libraries will suddenly have a lot of "you can 'uv add git+https://github.com/project/library'" instead of 'uv add library'.
I also don't think it would stop this attack, where a token was stolen.
If someone's generating pypi package releases from CI, they're going to register a credit card on their account, make it so CI can automatically charge it, and when the CI token is stolen it can push an update on the real package owner's dime, not the attackers, so it's not a deterrent.
Also, the iOS app store is an okay counter example. It charges $100/year for a developer account, but still has its share of malware (certainly more than the totally free debian software repository).
Re: My minute-by-minute response to the LiteLLM malware attack
#73Re: My minute-by-minute response to the LiteLLM malware attack
#74Re: My minute-by-minute response to the LiteLLM malware attack
#75Re: My minute-by-minute response to the LiteLLM malware attack
#76Re: My minute-by-minute response to the LiteLLM malware attack
#77Earlier quoted context omitted.
The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages. PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.
Would you happen to know where the latency comes from between upload and scanning? Would more resources for more security scanner runners to consume the scanner queue faster solve this? Trying to understand if there are inherent process limitations or if a donation for this compute would solve this gap. (software supply chain security is a component of my work)
I agree that's a bad idea to do so since security scanning is inherently a cat and mouse game.
Let's hypothetically say pypi did block upload on passing a security scan. The attacker now simply creates their own pypi test package ahead of time, uploads sample malicious payloads with additional layers of obfuscation until one passes the scan, and then uses that payload in the real attack.
Pypi would also probably open source any security scanning code it adds as part of upload (as it should), so the attacker could even just do it locally.
Re: My minute-by-minute response to the LiteLLM malware attack
#78Earlier quoted context omitted.
Would you happen to know where the latency comes from between upload and scanning? Would more resources for more security scanner runners to consume the scanner queue faster solve this? Trying to understand if there are inherent process limitations or if a donation for this compute would solve this gap. (software supply chain security is a component of my work)
He said, "pypi doesn't block upload on scanning"; that's part of where the latency comes from. The other part is simply the sheer mass of uploads, and that there's not money in doing it super quickly. I agree that's a bad idea to do so since security scanning is inherently a cat and mouse game. Let's hypothetically say pypi did block upload on passing a security scan. The attacker now simply creates their own pypi te…
("slow is smooth, smooth is fast")
Re: My minute-by-minute response to the LiteLLM malware attack
#79Earlier quoted context omitted.
> Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack) I think the attacks will get worse and more frequent -- ML tools enable doing it easily among people who were previously not competent enough to pull it off but now can. There is no stomach for the proper defensive measures among the community for either python or javascri…
Not only do the tools enable incompetent attackers, they also enable a new class of incompetent library developers to create and publish packages, and a new class of incompetent application developers to install packages without even knowing what packages are being used in the code they aren't reading, and a new class of incompetent users who are allowing OpenClaw to run completely arbitrary code on their machines wi…
Re: My minute-by-minute response to the LiteLLM malware attack
#80Earlier quoted context omitted.
>But I created $100k worth of code just yesterday recreating a poorly maintained (and poor ux) library. How, exactly, are you calculating the worth of your code? Did you manage to sell in the same day? Why is it "worth $100k"?
sloccount