301–310 of 569 posts
This is tied to the TeamPCP activity over the last few weeks. I've been responding, and keeping an up to date timeline. I hope it might help folks catch up and contextualize this incident: https://ramimac.me/trivy-teampcp/#phase-09
Migration guide: https://llmgateway.io/migration/litellm
What is the best way to sandbox LLMs and packages in general, while being able to work on data from outside sandbox (get data in and out easily)? There is also the need for data sanitation, because the attacker could distribute compromised files through user’s data which will later be run and compromise the host.
https://greyhaven.co/insights/how-greywall-prevents-every-st...
Earlier quoted context omitted.
They have written about it on github to my question: Trivvy hacked ( https://www.aquasec.com/blog/trivy-supply-chain-attack-what-... ) -> all circleci credentials leaked -> included pypi publish token + github pat -> | WE DISCOVER ISSUE | -> pypi token deleted, github pat deleted + account removed from org access, trivvy pinned to last known safe version (v0.69.3) What we're doing now: Block all releases, until we ha…
69.3 isnt safe. The safe thing to do is remove all trivy access. or failing that version. 0.35 is the last and AFAIK only safe version. https://socket.dev/blog/trivy-under-attack-again-github-acti...
https://github.com/BerriAI/litellm/issues/24518#issuecomment...
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…
Then we talk about containment like anyone actually looked at that dep list.
Even still though, we can't really trust any open-source software any more that has third party dependencies, because the chains can be so complex and long it's impossible to vet everything.
It's just too easy to spam out open-source software now, which also means it's too easy to create thousands of infected repos with sophisticated and clever supply chain attacks planted deeply inside them. Ones that can be surfaced at any time, too. LLMs have compounded this risk 100x.
I just installed Harbor, and it instantly pegged my cpu.. i was lucky to see my processes before the system hard locked. Basically it forkbombed `grep -r rpcuser\rpcpassword` processes trying to find cryptowallets or something. I saw that they spawned from harness, and killed it. Got lucky, no backdoor installed here from what i could make out of the binary
> i was lucky to see my processes before the system hard locked. how do you do that? have Activity Monitor up at all times?
LiteLLM maintainer here, this is still an evolving situation, but here's what we know so far: 1. Looks like this originated from the trivvy used in our ci/cd - https://github.com/search?q=repo%3ABerriAI%2Flitellm%20trivy... https://ramimac.me/trivy-teampcp/#phase-09 2. If you're on the proxy docker, you were not impacted. We pin our versions in the requirements.txt 3. The package is in quarantine on pypi - this block…
This must be super stressful for you, but I do want to note your "I'm sorry for this." It's really human. It is so much better than, you know... "We regret any inconvenience and remain committed to recognising the importance of maintaining trust with our valued community and following the duration of the ongoing transient issue we will continue to drive alignment on a comprehensive remediation framework going forward…
[flagged]
Earlier quoted context omitted.
Update: - Impacted versions (v1.82.7, v1.82.8) have been deleted from PyPI - All maintainer accounts have been changed - All keys for github, docker, circle ci, pip have been deleted We are still scanning our project to see if there's any more gaps. If you're a security expert and want to help, email me - krrish@berri.ai
Dropped you a mail from mads.havmand@nansen.ai