I have older versions of litellm installed on my system - it appears to be a dependency for aider-chat (at least on NixOS)
Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
431–440 of 569 posts
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#432Earlier quoted context omitted.
> It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive. Not really. Let's say I am running `~/src/project1 $ litellm` Why does this need access to anything outside of `~/src/project1`? Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else.
How are you setting that sandbox up? I've laid out numerous constraints - x-platform support is non-existent for sandboxing, sandboxing requires privileges to perform, whole-program sandboxing is fundamentally weaker, maintenance of sandboxing is best done by developers, etc. > Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else. Yes, but now you are in charge of…
> Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain.
Not really. I try to capture the most common ones for caching [1], but if I miss it, then it is just inefficient, as it is equivalent to a cache miss.
I'll emphasize again, "no linter/scanner/formatter (e.g., trivy) should need full disk access".
1 - https://github.com/ashishb/amazing-sandbox/blob/fddf04a90408...
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#433It 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…
How loud would it be?
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#434Earlier quoted context omitted.
It turns out that it's possible for the server to detect whether it is running via "| bash" or if it's just being downloaded. Inspecting it via download and then running that specific download is safer than sending it directly to bash, even if you download it and inspect it before redownloading it and piping it to a shell.
The server can also put malware in the .tar.gz. Are you really checking all the files in there, even the binaries? If you don't what's the point of checking only the install script?
> Are you really checking all the files in there, even the binaries?
One should never trust the binaries, always build them from source, all the way down to the bootloader.
Checking all the files is really the only way to deal with potential malware, or even security vulns.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#435Earlier quoted context omitted.
What would be really helpful is if software sandboxed itself. It's very painful to sandbox software from the outside and it's radically less effective because your sandbox is always maximally permissive. But, sadly, there's no x-platform way to do this, and sandboxing APIs are incredibly bad still and often require privileges. > It's easy to patch the security model of Linux with userspaces, and even easier with eBPF…
If the whole point of sandboxing is to not trust the software, it doesn't make sense for the software to do the sandboxing. (At most it should have a standard way to suggest what access it needs, and then your outside tooling should work with what's reasonable and alert on what isn't.) The android-like approach of sandboxing literally everything works because you are forced to solve these problems generically and at…
> If the whole point of sandboxing is to not trust the software, it doesn't make sense for the software to do the sandboxing.
That's true, sort of. I mean, that isn't the whole point of sandboxing because the threat model for sandboxing is pretty broad. You could have a process sandbox just one library, or sandbox itself in case of a vulnerability, or it could have a separate policy / manifest the way browser extensions do (that prompts users if it broadens), etc. There's still benefit to isolating whole processes though in case the process is malicious.
> (And no, most linux namespace stuff does not require root, the few things that do can be provided in more-controlled ways. For examples, look at podman, not docker.)
The only linux namespace that doesn't require root is user namespace, which basically requires root in practice. https://www.man7.org/linux/man-pages/man2/clone.2.html
Podman uses unprivileged user namespaces, which are disabled on the most popular distros because it's a big security hole.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#436Earlier quoted context omitted.
How are you setting that sandbox up? I've laid out numerous constraints - x-platform support is non-existent for sandboxing, sandboxing requires privileges to perform, whole-program sandboxing is fundamentally weaker, maintenance of sandboxing is best done by developers, etc. > Even if it does, you should expose exactly those particular directories (e.g. ~/.config) and nothing else. Yes, but now you are in charge of…
> Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain. Not really. I try to capture the most common ones for caching [1], but if I miss it, then it is just inefficient, as it is equivalent to a cache miss. I'll emphasize again, "no linter/scanner/formatter (e.g., trivy) should need full disk access". 1 - https://gi…
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 proxy. Are cache volumes shared? In that case, every container is compromised if one is. All of these problems and many more go away if the project is built around them from the start.
It's perfectly nice to wrap things up in docker but there's simply no argument here - developers can write sandboxes for their software more effectively because they can architect around the sandbox, you have to wrap the entire thing generically to support its maximum possible privileges.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#437Earlier quoted context omitted.
> Yes, but now you are in charge of knowing every potential file access, network access, or possibly even system call, for a program that you do not maintain. Not really. I try to capture the most common ones for caching [1], but if I miss it, then it is just inefficient, as it is equivalent to a cache miss. I'll emphasize again, "no linter/scanner/formatter (e.g., trivy) should need full disk access". 1 - https://gi…
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 `trivy`, it should not need access to tokens in a different env/directory.
> All of these problems and many more go away if the project is built around them from the start.
Please elaborate on your approach that will all me to run markdown/JS/Python/Go/Rust linters and security scanners. Remember that `trivy` which caused `litellm` compromise is a security scanner itself.
> developers can write sandboxes for their software more effectively because they can architect around the sandbox,
Yeah, let's ask 100+ linter providers to write sandboxes for you. I can't even get maintainers to respond to legitimate & trivial PRs many a time.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#438Earlier 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…
I'm not going to code review your sandbox project for you.
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#439Earlier quoted context omitted.
> - Krrish Was your account completely compromised? (Judging from the commit made by TeamPCP on your accounts) Are you in contacts with all the projects which use litellm downstream and if they are safe or not (I am assuming not) I am unable to understand how it compromised your account itself from the exploit at trivvy being used in CI/CD as well.
It was the PYPI_PUBLISH token which was in our github project as an env var, that got sent to trivvy. We have deleted all our pypi publishing tokens. Our accounts had 2fa, so it's a bad token here. We're reviewing our accounts, to see how we can make it more secure (trusted publishing via jwt tokens, move to a different pypi account, etc.).
Are you spelling it with two vs on purpose?
Re: Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised
#440[flagged]