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

511–520 of 569 posts

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

#511

Post by mike_hearn »

staticassertion wrote: post #490
mike_hearn wrote: post #465

Earlier quoted context omitted.

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 o…

Privesc is trivial on every desktop OS if you run as a regular user. I can write to your rc files so it's game over. App Store apps are the exception, which is great, but presumably we're not talking about that? If we are, then yeah, app stores solve these problems by making things actually sandboxed.

Any app can be sandboxed on macOS and by default newly created apps are; that's why I say if you create a new app in Xcode then anything run by that app is sandboxed out of the box. App Store enforces it but beyond that isn't involved.

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

#514

Post by dweinstein »

someguyornotidk wrote: post #462
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 standar…

hi, glad you like it and that it encourages you to try some things you've always wanted to do :-)

I was thinking for the license I'd do GPLv3. Would that work for you?

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

#515

Post by dweinstein »

huevosabio wrote: post #429
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…

This is clever, and also interesting in that it could help stop the steal as it happens (though of course not perfect).

thanks for your feedback!

that's a really good point and could be an interesting thing to play with as an extension. Since we potentially know which process is doing the "read" we could ask the user if it's ok to kill it. obviously the big issue is that we don't know how much has already been shipped off the system at that point but at least we have some alert to make some tough decisions.

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

#516

Post by bonoboTP »

tomtomtom777 wrote: post #503
postalcoder wrote: post #453

FYI, npm/bun/pnpm/uv now all support setting a minimum release age for packages. I updated my global configs to set min release age to 7 days: ~/.config/uv/uv.toml exclude-newer = "7 days" ~/.npmrc min-release-age=7 # days ~/Library/Preferences/pnpm/rc minimum-release-age=10080 # minutes ~/.bunfig.toml [install] minimumReleaseAge = 604800 # seconds

I understand that this is a good idea but it does feel really weird. Add a min-release-age to see if anyone who doesn't gets bitten. Next up, we're going to advise a minimum-release-age of 14 days, cause most other projects use 7 days.

You don't have to outrun the bear, just the other guy.

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

#518

Post by ashishb »

sellmesoap wrote: post #469
ashishb wrote: post #437

Earlier quoted context omitted.

> 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.

> docker run super-evil-oci-container

  1. That super evil OCI container still needs to find a vulnerability in Docker
  2. You can run Docker in rootless mode e.g. Orbstack runs without root

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

#520

Post by snailmailman »

snailmailman wrote: post #317
hiciu wrote: post #15

Besides main issue here, and the owners account being possibly compromised as well, there's like 170+ low quality spam comments in there. I would expect better spam detection system from GitHub. This is hardly acceptable.

The same thing occurred on the trivy repo a few days ago. A GitHub discussion about the hack was closed and 700+ spam comments were posted. I scrolled through and clicked a few profiles. While many might be spam accounts or low-activity accounts, some appeared to be actual GitHub users with a history of contributions. I’m curious how so many accounts got compromised. Are those past hacks, or is this credential steeli…

Update: It looks like the accounts have all been deleted by github, including their repos. They are 404 pages now. Their repos + recent malicious commits are all just 404 pages now.

I'm curious what the policy is there if the accounts were compromised. Can the original users "restore" their accounts somehow? For now it appears the accounts are gone. Maybe they were entirely bot accounts but a few looked like compromised "real" accounts to me.

Post reply on HN