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

261–270 of 569 posts

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

#261

Post by jFriedensreich »

dist-epoch wrote: post #214
jFriedensreich wrote: post #162

Earlier quoted context omitted.

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.

That assumes you even need an install script. 90% of install scripts just check the platform and make the binary executable and put it in the right place. Just give me links to a github release page with immutable releases enabled and pure binaries. I download the binary but it in a temporary folder, run it with a seatbelt profile that logs what it does. Binaries should "just run" and at most access one folder in a place they show you and that is configurable! Fuck installers.

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

#262

Post by beanaroo »

redrove wrote: post #94
sschueller wrote: post #29

Does anyone know a good alternate project that works similarly (share multipple LLMs across a set of users)? LiteLLM has been getting worse and trying to get me to upgrade to a paid version. I also had issues with creating tokens for other users etc.

Bifrost is the only real alternative I'm aware of https://github.com/maximhq/bifrost

We have tried reaching out to their sales multiple times but never get a response.

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

#263

Post by shados »

saganus wrote: post #241
eoskx wrote: post #192

Also, not surprising that LiteLLM's SOC2 auditor was Delve. The story writes itself.

Would a proper SOC2 audit have prevented this? I've been through SOC2 certifications in a few jobs and I'm not sure it makes you bullet proof, although maybe there's something I'm missing?

SOC2 is just "the process we say we have, is what we do in practice". The process can be almost anything. Some auditors will push on stuff as "required", but they're often wrong.

But all it means in the end is you can read up on how a company works and have some level of trust that they're not lying (too much).

It makes absolutely zero guarantees about security practices, unless the documented process make these guarantees.

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

#265

Post by fulafel »

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…

> In such an environment the container would crash, we see the violations, delete it and dont' have to worry about it.

This is the interesting part. What kind of UI or other mechanisms would help here? There's no silver bullet for detecting and crashing on "something bad". The adversary can test against your sandbox as well.

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

#266

Post by hmokiguess »

samsk wrote: post #158
f311a wrote: post #134

Their previous release would be easily caught by static analysis. PTH is a novel technique. Run all your new dependencies through static analysis and don't install the latest versions. I implemented static analysis for Python that detects close to 90% of such injections. https://github.com/rushter/hexora

Interesting tool, will definitely try - just curious, is there a tool (hexora checker) that ensures that hexora itself and its dependencies are not compromised ? And of course if there is one, I'll need another one for the hexora checker....

https://xkcd.com/2044/

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

#267

Post by MadsRC »

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

Dropped you a mail from mads.havmand@nansen.ai

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

#270

Post by ezekg »

redrove wrote: post #222
detente18 wrote: post #210

Earlier quoted context omitted.

It was the PYPI_PUBLISH token which was in our github project as an env var, that got sent to trivvy. We have deleted all our pypi publishing tokens. Our accounts had 2fa, so it's a bad token here. We're reviewing our accounts, to see how we can make it more secure (trusted publishing via jwt tokens, move to a different pypi account, etc.).

How did PYPI_PUBLISH lead to a full GH account takeover?

I'd imagine the attacker published a new compromised version of their package, which the author eventually downloaded, which pwned everything else.
Post reply on HN