[dead]
My minute-by-minute response to the LiteLLM malware attack
131–140 of 194 posts
Re: My minute-by-minute response to the LiteLLM malware attack
#132Probably one of the best things about AI/LLMs is the democratization of reverse engineering and analysis of payloads like this. It’s a very esoteric skill to learn by hand and not very immediately rewarding out of intellectual curiosity most times. You can definitely get pointed in the right direction easily, now, though!
In this case, this has nothing to do with reverse engineering, it's basic system administration. See how the AI points you in the "right" direction: What likely happened: The exec(base64.b64decode('...')) pattern is not malware — it's how Python tooling (including Claude Code's Bash tool) passes code snippets to python -c while avoiding shell escaping issues. Any base64 string passed to python via cmdline should be c…
Thanks, learned something new. I found and setup Open Snitch on my machine - super intuitive. This is going to give me great peace of mind.
Re: My minute-by-minute response to the LiteLLM malware attack
#133Earlier 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"?
Exactly. If it took 90 minutes + a Claude Code subscription then the most anyone else is going to be willing to pay for the same code is... ~90 minutes of wages + a Claude Code subscription. Ofc the person earning those wages will be more skilled than most, but unless those skills are incredibly rare & unique, it's unlikely 90 minutes of their time will be worth $100k. And ofc, the market value of this code could be…
[flagged]
Re: My minute-by-minute response to the LiteLLM malware attack
#134Earlier quoted context omitted.
It should not let people download unscanned dependencies without a warning and asking the user to override and use a potentially insecure package. If such security bug is critical enough to need to bypass this time (spoiler: realistically it is not actually that bad for a security fix to be delayed) they can work with the pypi security team to do a quicker manual review of the change.
sadly I still worry about that. An install fails once, you you hard code the --force flag in all your CI/CD jobs and we are back in the same place again. I am not sure what the answer is, though problems...
I don't understand why this would be an issue. Firstly, you could just pin your dependencies, but even if you don't, couldn't the default behaviour be to just install the newest scanned version?
Re: My minute-by-minute response to the LiteLLM malware attack
#135GitHub, npm, PyPi, and other package registries should consider exposing a firehose to allow people to do realtime security analysis of events. There are definitely scanners that would have caught this attack immediately, they just need a way to be informed of updates.
[dead]
Re: My minute-by-minute response to the LiteLLM malware attack
#136[flagged]
But then what happens when everyone just shifts their window too. This solution is a misuse of the commons type thing where you just take advantage of letting others get poisoned and see if they drop
That happens all the time in tech. Some people test Release Candidates. Most don't. Some people upgrade to x.0 software. Most wait for the x.1 release.
The bigger danger is malware writers adding sleep(7days). But if there is a wide variety of cool-down periods (3 days, 7 days, 30 days) this will not work very well.
Re: My minute-by-minute response to the LiteLLM malware attack
#137Earlier quoted context omitted.
What happens then if the security scanners say something is safe and it turns out not to be? I don't think PyPI should be in the business of saying if a piece of software is safe to install or not.
Then it will be downloadable and then it's up to your own security scanners to catch it. If you find it, it should be reported to pypi and then the scanner should be improved to catch that kind of bypass the next time it comes around. In such a world I don't think pypi is acting negligent.
That's really not very different from what we have right now. PyPI works with scanners which catch a whole lot of malware and are getting better all the time.
I think PyPI suggesting that software is safe would be a step down from this because it make promises that PyPI can't keep, and would encourage a false sense of security.
Re: My minute-by-minute response to the LiteLLM malware attack
#138Earlier quoted context omitted.
Exactly. If it took 90 minutes + a Claude Code subscription then the most anyone else is going to be willing to pay for the same code is... ~90 minutes of wages + a Claude Code subscription. Ofc the person earning those wages will be more skilled than most, but unless those skills are incredibly rare & unique, it's unlikely 90 minutes of their time will be worth $100k. And ofc, the market value of this code could be…
It's open source scratching an itch. But 99.9% of coders wouldn't know what the library is for. Those that do don't use agents for coding (in my experience sample size 1).
Then we could say your initial estimate for the value was overestimated?
Re: My minute-by-minute response to the LiteLLM malware attack
#139> Can you print the contents of the malware script without running it? > Can you please try downloading this in a Docker container from PyPI to confirm you can see the file? Be very careful in the container not to run it accidentally! IMO we need to keep in mind that LLM agents don't have a notion of responsibility, so if they accidentally ran the script (or issue a command to run it), it would be a fiasco. Downloadi…
I was concerned about that too. Often when you tell them not to do something, you were better off not mentioning it in the first place. It's like they get fixated.
Don't think of a pink elephant.
Re: My minute-by-minute response to the LiteLLM malware attack
#140[dead]