Live data from Hacker News

My minute-by-minute response to the LiteLLM malware attack

futuresearch.ai

71–80 of 194 posts

Re: My minute-by-minute response to the LiteLLM malware attack

#71

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…

Dear lord. Are you at least transparent with your clients that this is the standard to which you hold your own code?

Re: My minute-by-minute response to the LiteLLM malware attack

#72
post #49

Earlier 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.

I don't think people want to pay for that.

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

#77
post #49

Earlier 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)

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 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

#78
post #77

Earlier 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…

I suppose my argument is that pypi could offer the option to block downloads to package owners until a security scan is complete (if scanning will always take ~45-60 minutes), and if money is a problem, money can solve the scanning latency. Our org scans all packages ingested into artifact storage and requires dependency pinning, and would continue to do so, but more options (when cheap) are sometimes better imho. Also, not everyone has enterprise resources for managing this risk. I agree it is "cat and mouse" or "whack-a-mole", and always will be (ie building and maintaining systems of risk mitigation and reduction). We don't not do security scanning simply because adversaries are always improving, right? We collectively slow attackers down, when possible.

("slow is smooth, smooth is fast")

Re: My minute-by-minute response to the LiteLLM malware attack

#79

Earlier 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…

So basically the attacker and the dev who caught it were probably using the same tools if the malware was AI-generated (hence the fork bomb bug), and the investigation was AI-assisted (hence the speed). Less "tip of the iceberg" and more just that both sides got faster.

Re: My minute-by-minute response to the LiteLLM malware attack

#80
post #53

Earlier 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

That’s insane.
Post reply on HN