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

491–500 of 569 posts

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

#491

Post by imtringued »

sellmesoap wrote: post #469
ashishb wrote: post #437

Earlier quoted context omitted.

> Docker itself is privileged and now any unsandboxed program on your computer can trivially escalate to root. Inside the sandbox but not on my machine. Show me how it can access an unmounted directory. > Have you solved for publishing? You'll need your token to enter the container or you'll need an authorizing proxy. Amazing-sandbox does not solve for that. The current risk is contamination; if you are running `triv…

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

What's particularly vexing is that there is this agentic sandboxing software called "container-use" and out of the box it requires you to add a user to the docker group because they haven't thought about what that really means and why running docker in that configuration option shouldn't be allowed, but instead they have made it mandatory as a default.

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

#493

Post by leftyspook »

mikert89 wrote: post #364
zdragnar wrote: post #361

Earlier quoted context omitted.

Welcome to the new era, where programming is neither a skill nor a trade, but a task to be automated away by anyone with a paid subscription.

alot of software isnt that important so its fine, but some actually is important. especially with a branding name slapped on it that people will trust

All software runs on somebody's hardware. Ultimately even an utterly benign program like `cowsay` could be backdoored to upload your ssh keys somewhere.

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

#494

Post by BoppreH »

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…

The proposed solution seems to rely on a trusted compiler that generates the exact same output, bit-for-bit, as the compiler-under-test would generate if it was not compromised. That seems useful only in very narrow cases.

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

#495

Post by utrack »

leftyspook wrote: post #493
mikert89 wrote: post #364

Earlier quoted context omitted.

alot of software isnt that important so its fine, but some actually is important. especially with a branding name slapped on it that people will trust

All software runs on somebody's hardware. Ultimately even an utterly benign program like `cowsay` could be backdoored to upload your ssh keys somewhere.

https://xkcd.com/2347/ , but with `fortune -a` and `cowsay` instead of imagemagick

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

#496

Post by mark_l_watson »

arwt wrote: post #397
mark_l_watson wrote: post #239

Earlier quoted context omitted.

Good points. Perhaps there is a way to configure uv to only use a new version if it is 24 hours old?

You can. See: https://docs.astral.sh/uv/reference/cli/#uv-run--exclude-new... How you use it depends on your workflow. An entry like this in your pyproject.toml could suffice: [tool.uv] exclude-newer = "5 days"

thank you!

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

#498

Post by cpburns2009 »

ctmnt wrote: post #483
davidatbu wrote: post #474

Earlier quoted context omitted.

I don't think pypi or npm allow replacing existing packages?

They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.

1.82.7 and 1.82.8 were only up for about 3 hours before they were quarantined on PyPI.

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

#499

Post by cpburns2009 »

dec0dedab0de wrote: post #65

github, pypi, npm, homebrew, cpan, etc etc. should adopt a multi-multi-factor authentication approach for releases. Maybe have it kick in as a requirement after X amount of monthly downloads. Basically, have all releases require multi-factor auth from more than one person before they go live. A single person being compromised either technically, or by being hit on the head with a wrench, should not be able to release…

I really hoped PyPI's required switch to 2-factor auth would require reauthorization to publish packages. But no, they went with "trusted publishing" (i.e., publishing is triggered by CI, and will happily publish a compromized repo). Trusted publishing would only have been a minor hindrance to the litellm exploit. Since they acquired an account's personal access token, the exploit could have been committed to the repo and the package published.

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

#500

Post by vlovich123 »

BoppreH wrote: post #494
vlovich123 wrote: post #100

Earlier quoted context omitted.

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…

The proposed solution seems to rely on a trusted compiler that generates the exact same output, bit-for-bit, as the compiler-under-test would generate if it was not compromised. That seems useful only in very narrow cases.

You have a trusted compiler you write in assembly or even machine code. You then compile a source code you trust using that compiler. That is then used for the bit for bit analysis against a different binary of the compiler you produced to catch the hidden vulnerability.
Post reply on HN