Top
Best
New

Posted by Fibonar 6 hours ago

My minute-by-minute response to the LiteLLM malware attack(futuresearch.ai)
Related: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised - https://news.ycombinator.com/item?id=47501426 (483 comments)
211 points | 97 commentspage 3
Josephjackjrob1 3 hours ago|
This is pretty cool, when did you begin?
dmitrygr 5 hours ago||
Consider this your call to write native software. There is yet to be a supply chain attack on libc
woodruffw 5 hours ago||
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

everforward 5 hours ago|||
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 immediately use newly released stuff” by delaying their use of new versions. It starts to look an awful lot like apt/yum/dnf/etc.

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.

woodruffw 4 hours ago|||
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.

consp 4 hours ago|||
This is the security equivalent of having a better lock than your neighbour. Won't save you in the end but you won't be first. Then again, yours could also be broken and you don't get to tick of that audit checkbox.
dmitrygr 5 hours ago|||
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.

woodruffw 4 hours ago||
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.)

dmitrygr 4 hours ago||
Sane: debian-stable
woodruffw 4 hours ago||
From experience, a lot of people using a "stable" distro are just bypassing that distro's stability (read: staleness) by installing nightly things from a language ecosystem. It's not clear to me that this is a better (or worse) outcome than a less stable distro.
hrmtst93837 4 hours ago|||
Native code still have plenty of attack surface. If you do everything through pip/npm you might as well publish your root password, but pretending a clean C build from source makes you safe is just cosplay for people who confuse compiler output with trust. If anything people are way too quick to trust a tarball that builds on the first try.
dmitrygr 4 hours ago||
100% with you. Anything that builds from the first try is 100% malicious. No real software builds without 5-30 tweaks of the makefile. And anything on npm/pip is malicious with a fixed chance that you have no control over, as seen in this attack.

But the data remains: no supply chain attacks on libc yet, so even if it COULD happen, this HAS and that merely COULD.

mr_mitm 4 hours ago|||
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.
dmitrygr 4 hours ago||
Slower development velocity but no third-party-induced hacks surely has a market. :)
ddp26 5 hours ago|||
Sure, but this is a pretty onerous restriction.

Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)

ting0 4 hours ago|||
They will certainly get worse. LLMs make it so much easier.
dmitrygr 5 hours ago|||
> Do you think supply chain attacks will just get worse? I'm thinking that defensive measures will get better rapidly (especially after this hack)

I think the attacks will get worse and more frequent -- ML tools enable doing it easily among people who were previously not competent enough to pull it off but now can. There is no stomach for the proper defensive measures among the community for either python or javascript. Why am i so sure? This is not the first, second, third, or fourth time this has happened. Nothing changed.

applfanboysbgon 4 hours ago||
Not only do the tools enable incompetent attackers, they also enable a new class of incompetent library developers to create and publish packages, and a new class of incompetent application developers to install packages without even knowing what packages are being used in the code they aren't reading, and a new class of incompetent users who are allowing OpenClaw to run completely arbitrary code on their machines with no oversight. We are seeing only the tip of the iceberg of the security breaches that are to come.
mckennameyer 3 hours ago|||
So basically the attacker and the dev who caught it were probably using the same tools if the malware was AI-generated (hence the fork bomb bug), and the investigation was AI-assisted (hence the speed). Less "tip of the iceberg" and more just that both sides got faster.
dmitrygr 4 hours ago|||
100%
moralestapia 5 hours ago||
*salutes*

Thank you for your service, this brings so much context into view, it's great.

JulianPembroke 2 hours ago||
[dead]
qcautomation 2 hours ago||
[dead]
devnotes77 3 hours ago||
[dead]
Yanko_11 4 hours ago||
[dead]
aplomb1026 4 hours ago||
[dead]
__mharrison__ 4 hours ago|
Interesting world we live in.

I just finished teaching an advanced data science course for one of my clients. I found my self constantly twitching everytime I said "when I write code..." I'm barely writing code at all these days. But I created $100k worth of code just yesterday recreating a poorly maintained (and poor ux) library. Tested and uploaded to pypi in 90 minutes.

A lot of the conversation in my course was directed to leveraged AI (and discussions of existential dread of AI replacement).

This article is a wonderful example of an expert leveraging AI to do normal work 100x faster.

pxtail 4 hours ago||
Only $100k worth code? Rookie numbers, you must be new to the game
__mharrison__ 4 hours ago||
Doing my part to burn $50k tokens in a year as per the Jensen mandate.
anematode 3 hours ago|||
Dear lord. Are you at least transparent with your clients that this is the standard to which you hold your own code?
__mharrison__ 2 hours ago||
$100k was the quote of the project from sloccount... (No one paid me for this. I created it for myself.)
masijo 4 hours ago||
>But I created $100k worth of code just yesterday recreating a poorly maintained (and poor ux) library.

How, exactly, are you calculating the worth of your code? Did you manage to sell in the same day? Why is it "worth $100k"?

appreciatorBus 4 hours ago|||
Exactly.

If it took 90 minutes + a Claude Code subscription then the most anyone else is going to be willing to pay for the same code is... ~90 minutes of wages + a Claude Code subscription.

Ofc the person earning those wages will be more skilled than most, but unless those skills are incredibly rare & unique, it's unlikely 90 minutes of their time will be worth $100k.

And ofc, the market value of this code could be higher, even much higher, the the cost to produce it, but for this to be the case, there needs to be some sort of moat, some sort of reason another similarly skilled person cannot just use Claude to whip up something similar in their 90 minutes.

__mharrison__ 2 hours ago||
It's open source scratching an itch. But 99.9% of coders wouldn't know what the library is for. Those that do don't use agents for coding (in my experience sample size 1).
__mharrison__ 4 hours ago|||
sloccount
croemer 3 hours ago|||
So the more junk lines the more it's worth. Right.

Don't use bogus $ from sloccount. Just say I created a 10k line project.

__mharrison__ 2 hours ago||
Loc means nothing. Tokens burned is a better metric.
solarkraft 3 hours ago|||
That’s insane.