Live data from Hacker News

Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

github.com

111–120 of 569 posts

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

#111
post #23
post #15

Besides main issue here, and the owners account being possibly compromised as well, there's like 170+ low quality spam comments in there. I would expect better spam detection system from GitHub. This is hardly acceptable.

i'm guessing it's accounts they have compromised with the stealer.

They repeat only six sentences during 100+ comments:

Worked like a charm, much appreciated.

This was the answer I was looking for.

Thanks, that helped!

Thanks for the tip!

Great explanation, thanks for sharing.

This was the answer I was looking for.

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

#112

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…

Is it just in 1.82.8 or are previous versions impacted?

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

#113

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…

We need programming languages where every imported module is in its own sandbox by default.

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

#114
Am I the only one having feeling that with LLM-era we have now bigger amount of malicious software lets say parsers/fetchers of credentials/ssh/private keys? And it is easier to produce them and then include in some 3rd party open-source software? Or it is just our attention gets focused on such things?

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

#115

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…

Is it just in 1.82.8 or are previous versions impacted?

1.82.7 is also impacted if I remember correctly.

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

#116
post #95

If it was not spinning so many Python processes and not overwhelming the system with those (friends found out this is consuming too much CPU from the fan noise!) it would have been much more successful. So similar to xz attack it does a lot of CPU intensive work spawn background python decode embedded stage run inner collector if data collected: write attacker public key generate random AES key encrypt stolen data wi…

[deleted]

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

#117

I just installed Harbor, and it instantly pegged my cpu.. i was lucky to see my processes before the system hard locked. Basically it forkbombed `grep -r rpcuser\rpcpassword` processes trying to find cryptowallets or something. I saw that they spawned from harness, and killed it. Got lucky, no backdoor installed here from what i could make out of the binary

What is Harness?

Sorry i mean Harbor.. was running terminal bench

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

#118
post #95

If it was not spinning so many Python processes and not overwhelming the system with those (friends found out this is consuming too much CPU from the fan noise!) it would have been much more successful. So similar to xz attack it does a lot of CPU intensive work spawn background python decode embedded stage run inner collector if data collected: write attacker public key generate random AES key encrypt stolen data wi…

I can't tell which part of that is expensive unless many multiples of python are spawned at the same time. Are any of the payloads particularly large?

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

#119

Edit: ignore this silliness, as it sidesteps the real problem. Leaving it here because we shouldn't remove our own stupidity. It's pretty disappointing that safetensors has existed for multiple years now but people are still distributing pth files. Yes it requires more code to handle the loading and saving of models, but you'd think it would be worth it to avoid situations like this.

safetensors is just as vulnerable to this sort of exploit using a pth file since it's a Python package.

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

#120

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…

Containers prevent this kind of info stealing greatly, only explicitly provided creds would be leaked.
Post reply on HN