Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My minute-by-minute response to the LiteLLM malware attack

futuresearch.ai

Post reply on HN
Print view View original

41–50 of 194 posts

Re: My minute-by-minute response to the LiteLLM malware attack

#41

Post by woodruffw »

dmitrygr wrote: post #30
woodruffw wrote: post #14

Earlier quoted context omitted.

This is presumably because libc just doesn't change very often (not meaning code changes, but release cadence). But the average native software stack does have lots of things that change relatively often[1]. So "native" vs. not is probably not a salient factor. [1]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor

your link disproves your claim. no naive app depended on xz version >= latest. Most sane distros take time to up-rev. That is why the xz backdoor was, in fact, in NO stable distro And not changing often is a feature, yes.

I don't think it does; I think the industry opinion on xz is that we got lucky in terms of early detection, and that we shouldn't depend on luck.

(I don't know what a "sane" distro is; empirically lots of distros are bleeding-edge, so we need to think about these things regardless of value judgements.)

Re: My minute-by-minute response to the LiteLLM malware attack

#42

Post by mr_mitm »

dmitrygr wrote: post #8

Consider this your call to write native software. There is yet to be a supply chain attack on libc

Native software? You mean software without dependencies? Because I don't see how you solve the supply chain risk as long as you use dependencies. Sure, minimizing the number of dependencies and using mostly stable dependencies also minimizes the risk, but you'll pay for it with glacial development velocity.

Re: My minute-by-minute response to the LiteLLM malware attack

#43

Post by woodruffw »

everforward wrote: post #29
woodruffw wrote: post #14

Earlier quoted context omitted.

This is presumably because libc just doesn't change very often (not meaning code changes, but release cadence). But the average native software stack does have lots of things that change relatively often[1]. So "native" vs. not is probably not a salient factor. [1]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor

I think that article proves the opposite. > While xz is commonly present in most Linux distributions, at the time of discovery the backdoored version had not yet been widely deployed to production systems, but was present in development versions of major distributions. Ie if you weren’t running dev distros in prod, you probably weren’t exposed. Honestly a lot of packaging is coming back around to “maybe we shouldn’t…

Per below, xz is also an example of us getting lucky.

> I would wager in the near future we’ll have another revelation that having 10,000 dependencies is a bad thing because of supply chain attacks.

Yes, but this also has nothing to do with native vs. non-native.

Re: My minute-by-minute response to the LiteLLM malware attack

#44

Post by dmitrygr »

mr_mitm wrote: post #42
dmitrygr wrote: post #8

Consider this your call to write native software. There is yet to be a supply chain attack on libc

Native software? You mean software without dependencies? Because I don't see how you solve the supply chain risk as long as you use dependencies. Sure, minimizing the number of dependencies and using mostly stable dependencies also minimizes the risk, but you'll pay for it with glacial development velocity.

Slower development velocity but no third-party-induced hacks surely has a market. :)

Re: My minute-by-minute response to the LiteLLM malware attack

#45

Post by dmitrygr »

woodruffw wrote: post #41
dmitrygr wrote: post #30

Earlier quoted context omitted.

your link disproves your claim. no naive app depended on xz version >= latest. Most sane distros take time to up-rev. That is why the xz backdoor was, in fact, in NO stable distro And not changing often is a feature, yes.

I don't think it does; I think the industry opinion on xz is that we got lucky in terms of early detection, and that we shouldn't depend on luck. (I don't know what a "sane" distro is; empirically lots of distros are bleeding-edge, so we need to think about these things regardless of value judgements.)

Sane: debian-stable

Re: My minute-by-minute response to the LiteLLM malware attack

#47

Post by RALaBarge »

S0y wrote: post #26

> Where did the litellm files come from? Do you know which env? Are there reports of this online? > The litellm_init.pth IS in the official package manifest — the RECORD file lists it with a sha256 hash. This means it was shipped as part of the litellm==1.82.8 wheel on PyPI, not injected locally. > The infection chain: > Cursor → futuresearch-mcp-legacy (v0.6.0) → litellm (v1.82.8) → litellm_init.pth This is the scar…

Maybe the people who use emacs for everything are the only safe ones?

Re: My minute-by-minute response to the LiteLLM malware attack

#48

Post by lq9AJ8yrfs »

Fibonar wrote: post #2

Callum here, I was the developer that first discovered and reported the litellm vulnerability on Tuesday. I’m sharing the transcript of what it was like figuring out what was going on in real time, unedited with only minor redactions. I didn’t need to recount my thought process after the fact. It’s the very same ones I wrote down to help Claude figure out what was happening. I’m an ML engineer by trade, so having Cla…

As a sometimes peripheral and sometimes primary program manager for vulnerability disclosure, for companies you nearly can't avoid, $0.02 follows.

It's a signal vs noise thing. Most of the grief is caused by bottom feeders shoveling anything they can squint at and call a vulnerability and asking for money. Maybe once a month someone would run a free tool and blindly send snippets of the output promising the rest in exchange for payment. Or emailing the CFO and the General Counsel after being politely reminded to come back with high quality information, and then ignored until they do.

Your report on the other hand was high quality. I read all the reports that came my way, and good ones were fast tracked for fixes. I'd fix or mitigate them immediately if I had a way to do so without stopping business, and I'd go to the CISO, CTO, and the corresponding engineering manager if it mattered enough for immediate response.

Re: My minute-by-minute response to the LiteLLM malware attack

#49

Post by simonw »

charcircuit wrote: post #40
simonw wrote: post #12

Earlier quoted context omitted.

PyPI does exactly that, and it's been very effective. Security partners can scan packages and use the invite-only API to report them: https://blog.pypi.org/posts/2024-03-06-malware-reporting-evo...

It is not effective if it just takes a simple base64 encode to bypass. If Claude is trivially able to find that it is malicious then Pypi is being negligent.

The package in question was live for 46 minutes. It generally takes longer than that for security partners to scan and flag packages.

PyPI doesn't block package uploads awaiting security scanning - that would be a bad idea for a number of reasons, most notably (in my opinion) that it would be making promises that PyPI couldn't keep and lull people into a false sense of security.

Post reply on HN