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

221–230 of 569 posts

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

#221

Post by wang_li »

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.

It turns out that it's possible for the server to detect whether it is running via "| bash" or if it's just being downloaded. Inspecting it via download and then running that specific download is safer than sending it directly to bash, even if you download it and inspect it before redownloading it and piping it to a shell.

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

#222

Post by redrove »

detente18 wrote: post #210
Imustaskforhelp wrote: post #106

Earlier quoted context omitted.

> - Krrish Was your account completely compromised? (Judging from the commit made by TeamPCP on your accounts) Are you in contacts with all the projects which use litellm downstream and if they are safe or not (I am assuming not) I am unable to understand how it compromised your account itself from the exploit at trivvy being used in CI/CD as well.

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?

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

#223

Post by syllogism »

saidnooneever wrote: post #201
syllogism wrote: post #193

Maintainers need to keep a wall between the package publishing and public repos. Currently what people are doing is configuring the public repo as a Trusted Publisher directly. This means you can trigger the package publication from the repo itself, and the public repo is a huge surface area. Configure the CI to make a release with the artefacts attached. Then have an entirely private repo that can't be triggered aut…

this kind of compromise is why a lot of orgs have internal mirrors of repos or package sources so they can stay behind few versions to avoid latest and compromise. seen it with internal pip repos, apt repos etc. some will even audit each package in there (kind crap job but it works fairly well as mitigation)

Just keeping a lockfile and updating it weekly works fine for that too yeah

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

#224

Post by saidnooneever »

amelius wrote: post #205
saidnooneever wrote: post #199

Earlier quoted context omitted.

just sandbox the interpreter (in this case), package manager and binaries. u can run in chroot jail and it wouldnt have accessed ssh keys outside of the jail... theres many more similar technologies aleady existing, for decades. doing it on a per language basis is not ideal. any new language would have to reinvent the wheel. better to do it at system level. with the already existing tooling. openbsd has plege/unveil,…

What if I wanted to write a program that uses untrusted libraries, but also does some very security sensitive stuff? You are probably going to suggest splitting the program into microservices. But that has a lot of problems and makes things slow. The problem is that programs can be entire systems, so "doing it at the system level" still means that you'd have to build boundaries inside a program.

you can do multi process things. or drop privs when using untrusted things.

you can use OS apis to isolate the thing u want to use just fine..

and yes, if you mix privilege levels in a program by design then u will have to design your program for that.

this is simple logic.

a programming language can not decide for you who and what you trust.

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

#225

Post by dist-epoch »

wang_li wrote: post #221
dist-epoch wrote: post #214

Earlier quoted context omitted.

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.

It turns out that it's possible for the server to detect whether it is running via "| bash" or if it's just being downloaded. Inspecting it via download and then running that specific download is safer than sending it directly to bash, even if you download it and inspect it before redownloading it and piping it to a shell.

The server can also put malware in the .tar.gz. Are you really checking all the files in there, even the binaries? If you don't what's the point of checking only the install script?

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

#226

Post by klibertp »

cedws wrote: post #129
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…

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.

The NIH syndrome becoming best practice (a commenter below already says they "vibe-coded replacements for many dependencies") would also save quite a few jobs, I suspect. Fun times.

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

#228

Post by amelius »

saidnooneever wrote: post #224
amelius wrote: post #205

Earlier quoted context omitted.

What if I wanted to write a program that uses untrusted libraries, but also does some very security sensitive stuff? You are probably going to suggest splitting the program into microservices. But that has a lot of problems and makes things slow. The problem is that programs can be entire systems, so "doing it at the system level" still means that you'd have to build boundaries inside a program.

you can do multi process things. or drop privs when using untrusted things. you can use OS apis to isolate the thing u want to use just fine.. and yes, if you mix privilege levels in a program by design then u will have to design your program for that. this is simple logic. a programming language can not decide for you who and what you trust.

> you can use OS apis to isolate the thing u want to use just fine..

For the sake of the argument, what if I wanted to isolate numpy from scipy?

Would you run numpy in a separate process from scipy? How would you share data between them?

Yes, you __can__ do all of that without programming language support. However, language support can make it much easier.

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

#229

Post by dlor »

6thbit wrote: post #35

title is bit misleading. The package was directly compromised, not “by supply chain attack”. If you use the compromised package, your supply chain is compromised.

It's both. They got compromised by another supply chain attack on Trivy initially.

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

#230

Post by [deleted] »

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…

[deleted]
Post reply on HN