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

321–330 of 569 posts

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

#321

Post by nimih »

dotancohen wrote: post #286
adw wrote: post #177

Earlier quoted context omitted.

> In one of my vibe coded personal projects (Python and Rust project) I'm actually getting rid of most dependencies and vibe coding replacements that do just what I need. I think that we'll see far fewer dependencies in future projects. No free lunch. LLMs are capable of writing exploitable code and you don’t get notifications (in the eg Dependabot sense, though it has its own problems) without audits.

My vibe coded personal projects don't have the source code available for attackers to target specifically.

It might surprise you to learn that a large number of software exploits are written without the attacker having direct access to the program's source code. In fact, shocking as it may seem today, huge numbers of computers running the Windows operating system and Internet Explorer were compromised without the attackers ever having access to the source code of either.

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

#322

Post by ting0 »

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.

Stop scaring me.

You're right though. There's been talks of a big global hack attack for a while now.

Nothing is safe anymore. Keep everything private airgapped is the only way forward. But most of our private and personal data is in the cloud, and we have no control over it or the backups that these companies keep.

While LLMs unlock the opportunity to self-host and self-create your infrastructure, it also unleashes the world of pain that is coming our way.

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

#323

Post by MetaWhirledPeas »

ting0 wrote: post #315
cedws wrote: post #129

Earlier quoted context omitted.

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.

What we need is accountability and ties to real-world identity. If you're compromised, you're burned forever in the ledger. It's the only way a trust model can work. The threat of being forever tainted is enough to make people more cautious, and attackers will have no way to pull off attacks unless they steal identities of powerful nodes. Like, it shouldn't be a thing that some large open-source project has some 4th…

> real-world identity

This bit sounds like dystopian governance, antithetical to most open source philosophies.

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

#324

Post by itintheory »

redrove wrote: post #84
xinayder wrote: post #61

When something like this happens, do security researchers instantly contact the hosting companies to suspend or block the domains used by the attackers?

First line of defense is the git host and artifact host scrape the malware clean (in this case GitHub and Pypi). Domains might get added to a list for things like 1.1.1.2 but as you can imagine that has much smaller coverage, not everyone uses something like this in their DNS infra.

This threat actor is also using Internet Computer Protocol (ICP) "Canisters" to deliver payloads. I'm not too familiar with the project, but I'm not sure blocking domains in DNS would help there.

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

#325

Post by Aurornis »

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…

> Dev containers were never good enough, too clumsy and too little isolation.

I haven't kept up with the recent exploits, so a side question: Have any of the recent supply chain attacks or related exploits included any escapes from basic dev containers?

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

#328

Post by 2OEH8eoCRo0 »

MetaWhirledPeas wrote: post #323
ting0 wrote: post #315

Earlier quoted context omitted.

What we need is accountability and ties to real-world identity. If you're compromised, you're burned forever in the ledger. It's the only way a trust model can work. The threat of being forever tainted is enough to make people more cautious, and attackers will have no way to pull off attacks unless they steal identities of powerful nodes. Like, it shouldn't be a thing that some large open-source project has some 4th…

> real-world identity This bit sounds like dystopian governance, antithetical to most open source philosophies.

Would you drive on bridges or ride in elevators "inspected" by anons? Why are our standards for digital infrastructure and software "engineering" so low?

I don't blame the anons but the people blindly pulling in anon dependencies. The anons don't owe us anything.

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

#330

Post by ting0 »

Havoc wrote: post #295
shay_ker wrote: post #58

A general question - how do frontier AI companies handle scenarios like this in their training data? If they train their models naively, then training data injection seems very possible and could make models silently pwn people. Do the labs label code versions with an associated CVE to label them as compromised (telling the model what NOT to do)? Do they do adversarial RL environments to teach what's good/bad? I'm ve…

By betting that it dilutes away and not worrying about it too much. Bit like dropping radioactive barrels into the deep ocean.

Yeah, and that won't hold up for long. Just wait until some well resourced attacker replicates their exploit into tens of thousands of sources it knows will be scraped and included in the training set to bias the model to produce their vulnerable code. Only a matter of time.
Post reply on HN