Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

341–350 of 569 posts

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#341
post #315
post #129

Earlier quoted context omitted.

This is the security shortcuts of the past 50 years coming back to bite us. Software has historically been a world where we all just trust each other. I think that’s coming to an end very soon. We need sandboxing for sure, but it’s much bigger than that. Entire security models need to be rethought.

What we need is accountability and ties to real-world identity. If you're compromised, you're burned forever in the ledger. It's the only way a trust model can work. The threat of being forever tainted is enough to make people more cautious, and attackers will have no way to pull off attacks unless they steal identities of powerful nodes. Like, it shouldn't be a thing that some large open-source project has some 4th…

> The threat of being forever tainted is enough to make people more cautious

No it's not. The blame game was very popular in the Eastern Block and it resulted in a stagnant society where lots of things went wrong anyway. For instance, Chernobyl.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#342
post #180

I wonder at what point ecosystems just force a credential rotation. Trivy and now LiteLLM have probably cleaned out a sizable number of credentials, and now it's up to each person and/or team to rotate. TeamPCP is sitting on a treasure trove of credentials and based on this, they're probably carefully mapping out what they can exploit and building payloads for each one. It would be interesting if Python, NPM, Rubygem…

It'll only be disruptive to people who are improperly managing their credentials. Cattle not pets applies to credentials too.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#343

Perhaps I'm missing something obvious - but what's up with the comments on the reported issue? Hundreds of downvoted comments like "Worked like a charm, much appreciated.", "Thanks, that helped!", and "Great explanation, thanks for sharing."

Compromised accounts. The malware targeted ~/.git-credentials.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#345

my takeaway from this is that it should now be MANDATORY to have an LLM do a scan on the entire codebase prior to release or artifact creation. do NOT use third party plugins for this. it's so easy to create your own github action to digest the whole codebase and inspect third party code. it costs tokens yes but it's also cached and should be negligible spend for the security it brings.

Ironically, Trivy was the first known compromised package and its purpose is to scan container images to make sure they don't contain vulnerabilities. Kinda like the LLM in your scenario.

Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

#348

Earlier quoted context omitted.

Sure, and that is basically what sane people do now, but that only works until something needs a security patch that was not provided for the old version, and changing one dependency is likely to cascade so now I am open to supply chain attacks in many dependencies again (even if briefly). To really run code without trust would need something more like a microkernel that is the only thing in my system I have to trust…

Virtual machines are that - tiny surfaces to access the host system (block disk device, ...). Which is why virtual machine escape vulnerabilities are quite rare.

I feel like in some cases we should be using virtual machines. Especially in domains where risk is non-trivial.

How do you change developer and user habits though? It's not as easy as people think.

Post reply on HN