Hacker News

TIL! this is cool

No no it's really important that I have 5-factor authentication on every website and it requires me to go through the whole login process again every time I break eye contact.

What are you talking about? Even dependency cooldown of 24h is enough to protect the consumers from these breaches. The attack did not have any novelty, used a newly registered look-alike domain for C2 and a PTH technique which is now known.

Sandbox comes in for the unknown ones and yes, its a pain to get the profile right.

Fuchsia solved that

> Unix and Linux solved all this even before Alexander III of Macedon started wearing his nappies

I mean, didn't Linux shells invent pop-up fatigue? I thought we (yes, we) all used to -y flag preemptively so the upgrades and installations/setups go through. Linux really did do it first, the agents are just more needy and their popups more verbose now, but not exactly new.

VM isn't a silver bullet.

The compromise appears somewhere in the build and deploy system.

> No public commit in BerriAI/litellm contains data = "cook" or a cook/ folder.

> SafeDep assesses, with moderate to high confidence, that BerriAI’s private release pipeline built these wheels from an attacker-modified git source.

Every harness thinking right now… "if we want do something like this we won't even have to compromise anything."

Sarcasm?

If that's right then attestations wouldn't have saved anyone here either. They prove which workflow published the wheel, not what source that workflow checked out. A private pipeline building from the same-looking repo still gives you a perfectly valid attestation.

What would catch it is someone rebuilding from the public tag and comparing the result, which almost nobody does for the python wheels. I have been treating attestations as the answer for my own project's releases, so this is a good reminder of where they stop.

I use safechain for this, because there is always gonna be another package manager configured wrong. https://github.com/AikidoSec/safe-chain

I’d imagine there were probably fixes for critical CVEs that were included …. A lot of companies are on a 24 hour timeline to get them out.

We have 7d cooldown on packages on an internal pypi proxy but that blocks security updates also, which we now have to manually exclude from the cooldown.

I’m unsure how to automate this properly, maybe an LLM is the best starting point.

I didn't realize they've all such added that, this was a change we made to our own projects last year when these first started - glad to see it's common.

Risk is ensuring enough security researchers are finding these and quarantining these before that default cooldown lapses.

The last time I looked for information, I remember seeing that the median supply chain attack was in place for multiple months to years before being discovered. Cooldowns shorter than that seem like snake oil.

I wonder if in some cases it's not so much that people are updating too quickly, but rather, their deployment pipelines do not have pinned / frozen versions attached to their builds.

Then we’ll find out about malware 24 - 48 hours later.

Yeah, thinking that after the last supply chain attack, people would be smarter than ship things with LiteLLM.

Is that you Max?

What's interesting here is that this will only affect those who did not migrate off LiteLLM after it was attacked the first time.

I'm not saying everyong should migrate after there's a vuln, but I'm definitely saying that. Unless it's something huge and foundational like a programming language (PHP gets a second chance), just migrate within the next couple of weeks.

I didn't even have it installed the first time, so the ideal programmers, (read, your competition), actually suffered 0 vulns from this dep, if you suffered 1, that's already pretty bad, being burnt twice should be a wake up call. If you get hit 3 times by the same dependency, it's a lost case.

all popular, free, ungated software will be poisoned; like kesler syndrome but for the world of open source software.

[dead]

Déjà vu for both of us, huh?

So they sell advance access to information that will allow me to hack other people's LiteLLM instances?

Seems a little unethical

Sounds like a reasonable choice of a language.

I myself have written a small llm proxy in Go, doing nothing but injecting the real API key to outgoing requests while itself validating virtual keys it generates, and it works great.

If you don't use any LLM router, it's infinity times faster, and infitesimally as targetted.

Bytesafe (https://bytesafe.dev). Pure Dependency Firewall, not a package host, with usage based pricing.

This one ? https://news.ycombinator.com/item?id=46909037

I use it, I don't cooldown, proper version pinning for me.

Not sure about a service, but PMG enforces dependency cooldown and sandbox on package install. https://github.com/safedep/pmg

Socket.dev

Tell em Tom Zubiri sent ya (I don't get a commission, just good karma)

man, people are going to be sorely disappointed in what's free on the internet in a couple of years.

Agents and malware will eradicate all goodwill left.

Good by internet.

[flagged]

Yes if you use LLM to analyse everything. Not really if you analyse diffs, with heuristics to select candidates for LLM/agent based analysis. But at the cost of missing out novel attacks.

it's just the poor styling of the selection highlight colour.

don't forget today's NodeJS security update addressing its own RCE bugs!

is the google outage related to a security incident?

Note: I work at LiteLLM

There exists a critical vulnerability which affects only Enterprise LiteLLM deployments, and does not affect OSS deployments.

We have provided our customers with patched releases distributed via a private registry and are allowing them some time to update their deployments before we release the fix in our public registry and disclose the vulnerability details. Releasing the fix publicly in an open source product would be a de-facto vulnerability disclosure.

That's not what's being said, at all. They are simply telling their enterprise customers that there is a different build pathway for the enterprise builds and that pathway wasn't impacted by this issue.

Also if you don't like organizations fixing vulns without releasing the open source first, you're going to be upset when you learn how every major vuln and associated patches are distributed long before the fixes hit the repos. A timely example of this is PHP, literally today.

There are over 8 billion people on Earth, and some subset of the computer systems that they all use are going to have issues, every day.

It's really not as bad as the accumulated headlines and exploitative hype make it sound.

It's similar to the mass hysteria and moral panics over things like child abduction. Media reports make certain dangers seem much more important than they really are, when considered in context.

Welcome to the AI era, every week in the near future