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

521–530 of 569 posts

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

#521

Post by detente18 »

cosmicweather wrote: post #215
detente18 wrote: post #209

Earlier quoted context omitted.

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?

I deleted it, to be safe.

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

#522

Post by talkin »

tomtomtom777 wrote: post #503
postalcoder wrote: post #453

FYI, npm/bun/pnpm/uv now all support setting a minimum release age for packages. I updated my global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds

I understand that this is a good idea but it does feel really weird. Add a min-release-age to see if anyone who doesn't gets bitten. Next up, we're going to advise a minimum-release-age of 14 days, cause most other projects use 7 days.

There will always be early adopters.

And maybe more importantly: security tools and researchers.

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

#523

Post by howlin »

PunchyHamster wrote: post #466
dec0dedab0de wrote: post #142

Earlier quoted context omitted.

Over the last ~15 years I have been shocked by the amount of spam on social networks that could have been caught with a Bayesian filter. Or in this case, a fairly simple regex.

It's the bear trash lock problem all over again. It could be solved by the filter but filter would also have a bunch of false positives

It seems like if the content is this hollow and useless, it shouldn't matter if it was a human or spambot posting it.

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

#524

Post by autoexec »

encomiast wrote: post #473
hannahoppla wrote: post #461

Earlier quoted context omitted.

Accountability is on the people using a billion third party dependencies, you need to take responsibility for every line of code you use in your project.

If you are really talking about dependencies, I’m not sure you’ve really thought this all the way through. Are you inspecting every line of the Python interpreter and its dependencies before running? Are you reading the compiler that built the Python interpreter?

It's still smart to limit the amount of code (and coders) you have to trust. A large project like Python should be making sure it's dependencies are safe before each release. In our own projects we'd probably be better off taking just the code we need from a library, verifying it (at least to the extent of looking for something as suspect as a random block of base64 encoded data) and copying it into our projects directly rather than adding a ton of external dependencies and every last one of the dependencies they pull in and then just hoping that nobody anywhere in that chain gets compromised.

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

#526

Post by [deleted] »

vlovich123 wrote: post #100
rdevilla wrote: post #50

It will only take one agent-led compromise to get some Claude-authored underhanded C into llvm or linux or something and then we will all finally need to reflect on trusting trust at last and forevermore.

Reflect in what way? The primary focus of that talk is that it’s possible to infect the binary of a compiler in a way that source analysis won’t reveal and the binary self replicates the vulnerability into other binaries it generates. Thankfully that particular problem was “solved” a while back [1] even if not yet implemented widely. However, the broader idea of supply chain attacks remains challenging and AI doesn’t…

[deleted]

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

#527

Post by jFriedensreich »

lyu07282 wrote: post #454
jFriedensreich wrote: post #249

Earlier quoted context omitted.

Just because this attack example did not contain container escape exploits does not mean this is safe. Its better than nothing but nothing that will save us.

Those supply chain attacks we are seeing are bad, but if someone burns a 0day container escape for it, it would probably be a net positive effect on security overall. Just saying this is FUD.

FUD is crypto and tech bro speech. Using containers without vm, gvisor or similar is just irresponsible.

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

#529

Post by lyu07282 »

jFriedensreich wrote: post #527
lyu07282 wrote: post #454

Earlier quoted context omitted.

Those supply chain attacks we are seeing are bad, but if someone burns a 0day container escape for it, it would probably be a net positive effect on security overall. Just saying this is FUD.

FUD is crypto and tech bro speech. Using containers without vm, gvisor or similar is just irresponsible.

Oh you are young, FUD was criticism to IBM sales people scaring customers away from PC compatible clones.

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

#530

Post by staticassertion »

ashishb wrote: post #518
sellmesoap wrote: post #469

Earlier quoted context omitted.

> Inside the sandbox but not on my machine. Show me how it can access an unmounted directory. So it says right on the tin of my favorite distro: 'Warning: Beware that the docker group membership is effectively equivalent to being root! Consider using rootless mode below.' So # docker run super-evil-oci-container with a bind mount or two and your would-be attacker doesn't need to guess your sudo password.

> docker run super-evil-oci-container 1. That super evil OCI container still needs to find a vulnerability in Docker 2. You can run Docker in rootless mode e.g. Orbstack runs without root

They're suggesting that the attacker is in a position to `docker run`. Any attacker in that position has privesc to root, trivially.

Rootless mode requires unprivileged user namespaces, disabled on almost any distribution because it's a huge security hole in and of itself.

Post reply on HN