Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

Post reply on HN
Print view View original

211–220 of 569 posts

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

#211

Post by dist-epoch »

1313ed01 wrote: post #167
dotancohen wrote: post #156

Earlier quoted context omitted.

> This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. For the most part you can. Just version pin slightly-stale versions of dependencies, after ensuring there are no known exploits for that version. Avoid the latest updates whenever possible. And keep aware of s…

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.

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

#212

Post by aftbit »

1313ed01 wrote: post #147
cedws wrote: 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.

This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in. If the sandbox, or the operating system the sandbox run…

The secure boot "shim" is a project like this. Perhaps we need more core projects that can be simple and small enough to reach a "finished" state where they are unlikely to need future upgrades for any reason. Formal verification could help with this ... maybe.

https://wiki.debian.org/SecureBoot#Shim

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

#213

Post by [deleted] »

soco wrote: post #38
jadamson wrote: post #21

Earlier quoted context omitted.

Most his recent commits are small edits claiming responsibility on behalf of "teampcp", which was the group behind the recent Trivy compromise: https://news.ycombinator.com/item?id=47475888

I was just wondering why the Trivy compromise hit only npm packages, thinking that bigger stuff should appear sooner or later. Here we go...

[deleted]

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

#214

Post by dist-epoch »

jFriedensreich wrote: post #162
binsquare wrote: post #109

Earlier quoted context omitted.

So... I'm working on an open source technology to make a literal virtual machine shippable i.e. freezing everything inside it, isolated due to vm/hypervisor for sandboxing, with support for containers too since it's a real linux vm. The problems you mentioned resonated a lot with me and why I'm building it, any interest in working to solve that together?: https://github.com/smol-machines/smolvm

Thanks for the pointer! Love the premise project. Just a few notes: - a security focused project should NOT default to train people installing by piping to bash. If i try previewing the install script in the browser it forces download instead of showing as plain text. The first thing i see is an argument # --prefix DIR Install to DIR (default: ~/.smolvm) that later in the script is rm -rf deleting a lib folder. So if…

What is the alternative to bash piping? If you don't trust the project install script, why would you trust the project itself? You can put malware in either.

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

#215

Post by cosmicweather »

detente18 wrote: post #209
detente18 wrote: post #99

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

Update: - Impacted versions (v1.82.7, v1.82.8) have been deleted from PyPI - All maintainer accounts have been changed - All keys for github, docker, circle ci, pip have been deleted We are still scanning our project to see if there's any more gaps. If you're a security expert and want to help, email me - krrish@berri.ai

> All maintainer accounts have been changed

What about the compromised accounts(as in your main account)? Are they completely unrecoverable?

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

#216

Post by udave »

jFriedensreich wrote: post #86

We just can't trust dependencies and dev setups. I wanted to say "anymore" but we never could. Dev containers were never good enough, too clumsy and too little isolation. We need to start working in full sandboxes with defence in depth that have real guardrails and UIs like vm isolation + container primitives and allow lists, egress filters, seccomp, gvisor and more but with much better usability. Its the same requir…

strongly agree. we keep giving away trust to other entities in order to make our jobs easier. trusting maintainers is still better than trusting a clanker but still risky. We need a sandboxed environment where we can build our software without having to worry about these unreliable factors.

On a personal note, I have been developing and talking to a clanker ( runs inside ) to get my day to day work done. I can have multiple instances of my project using worktrees, have them share some common dependencies and monitor all of them in one place. I plan to opensource this framework soon.

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

#217

Post by wang_li »

1313ed01 wrote: post #147
cedws wrote: 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.

This assumes that we can get a locked down, secure, stable bedrock system and sandbox that basically never changes except for tiny security updates that can be carefully inspected by many independent parties. Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in. If the sandbox, or the operating system the sandbox run…

>Which sounds great, but the way things work now tend to be the exact opposite of that, so there will be no trustable platform to run the untrusted code in.

This is the problem with software progressivism. Some things really should just be what they are, you fix bugs and security issues and you don't constantly add features. Instead everyone is trying to make everything have every feature. Constantly fiddling around in the guts of stuff and constantly adding new bugs and security problems.

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

#220

Post by ozozozd »

detente18 wrote: post #99

LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…

Kudos for this update.

Write a detailed postmortem, share it publicly, continue taking responsibility, and you will come out of this having earned an immense amount respect.

Post reply on HN