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

461–470 of 569 posts

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

#461

Post by hannahoppla »

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…

Accountability is on the people using a billion third party dependencies, you need to take responsibility for every line of code you use in your project.

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

#462

Post by someguyornotidk »

dweinstein wrote: post #363

https://github.com/dweinstein/canary I made this tool for macos systems that helps detect when a package accesses something it shouldn't. it's a tiny go binary (less than 2k LOC) with no dependencies that will mount a webdav filesystem (no root) or NFS (root required) with fake secrets and send you a notification when anything accesses it. Very stupid simple. I've always really liked the canary/honeypot approach and…

Thank you for sharing this!

I always wanted to mess with building virtual filesystems but was unwilling to venture outside the standard library (i.e. libfuse) for reasons wonderfully illustrated in this thread and elsewhere. Somehow the idea of implementing a networked fs protocol and leaving system integration to the system never crossed my mind.

I'm glad more people are taking this stance. Large centralized standard libraries and minimal audited dependencies is really the only way to achieve some semblance of security. There is simply no other viable approach.

Edit: What's the license for this project?

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

#463

Post by codethief »

amelius wrote: post #113
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…

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

Or just make side effects explicit in the type system through monads or algebraic effects.

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

#464

Post by sersi »

nimih wrote: post #321
dotancohen wrote: post #286

Earlier quoted context omitted.

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.

I'm actually curious if the windows source code leak of 2004 increased the number of exploits against windows? I'm not sure if it included internet explorer. I remember that windows 2000 was included back then.

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

#465

Post by mike_hearn »

staticassertion wrote: post #320
mike_hearn wrote: post #319

Earlier quoted context omitted.

User isolation works, the keychain isolation works. On macOS tokens stored in the keychain can be made readable only by specific apps, not anything else. It does require a bit of infrastructure - ideally a Mac app that does the release - but nothing you can't vibe code quickly.

That's true, but it seems far more complex than just moving trivy to a separate workerflow with no permissions and likely physical isolation between it and a credential. I'm pretty wary of the idea that malware couldn't just privesc - it's pretty trivial to obtain root on a user's laptop. Running as a separate, unprivileged user helps a ton, but again, I'm skeptical of this vs just using a github workflow.

I'm looking for more general solutions. "Properly configure Trivy" is too specific, it's obvious in hindsight but not before.

Privilege escalation on macOS is very hard indeed. Apple have been improving security for a long time, it is far, far ahead of Linux or Windows in this regard. The default experience in Xcode is that a release-mode app you make will be sandboxed, undebuggable, have protected keychain entries other apps can't read, have a protected file space other apps can't read, and its own code will also be read-only to other apps. So apps can't interfere with each other or escalate to each other's privileges even when running as the same UNIX user. And that's the default, you don't have to do anything to get that level of protection.

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

#466

Post by PunchyHamster »

dec0dedab0de wrote: post #142
ebonnafoux wrote: post #111

Earlier quoted context omitted.

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.

Over the last ~15 years I have been shocked by the amount of spam on social networks that could have been caught with a Bayesian filter. Or in this case, a fairly simple regex.

It's the bear trash lock problem all over again.

It could be solved by the filter but filter would also have a bunch of false positives

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

#467

Post by PunchyHamster »

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.

"we" ? "We" know. We just can't do much about people on LLM crack that will go around any and every quality step just to tell themselves the LLM made them x times more productive

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

#469

Post by sellmesoap »

ashishb wrote: post #437
staticassertion wrote: post #436

Earlier quoted context omitted.

Okay, so you're using docker. Cool, that's one of the only x-plat ways to get any sandboxing. Docker itself is privileged and now any unsandboxed program on your computer can trivially escalate to root. It also doesn't limit nearly as much as a dev-built sandbox because it has to isolate the entire process. Have you solved for publishing? You'll need your token to enter the container or you'll need an authorizing pro…

> Docker itself is privileged and now any unsandboxed program on your computer can trivially escalate to root. Inside the sandbox but not on my machine. Show me how it can access an unmounted directory. > Have you solved for publishing? You'll need your token to enter the container or you'll need an authorizing proxy. Amazing-sandbox does not solve for that. The current risk is contamination; if you are running `triv…

> Inside the sandbox but not on my machine. Show me how it can access an unmounted directory.

So it says right on the tin of my favorite distro: 'Warning: Beware that the docker group membership is effectively equivalent to being root! Consider using rootless mode below.' So # docker run super-evil-oci-container with a bind mount or two and your would-be attacker doesn't need to guess your sudo password.

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

#470

Post by ramimac »

avian wrote: post #468

What's with the hundreds of comments like "This was the answer I was looking for." in that GitHub thread? They also seem to be spilling into HN [1]. Runaway AI agents? A meme I'm to old to understand? [1] https://news.ycombinator.com/item?id=47508315

It's a spam flood by the attacker to complicate information sharing[1]. They did the same thing in the Trivy discussion, with many of the same accounts.[2]

[1] https://ramimac.me/teampcp/#spam-flood-litellm [2] https://ramimac.me/teampcp/#discussion-flooded

Post reply on HN