7 ms·
You don't need a full air gap. Set up a microVM with network access limited to local network and send all package requests through a filtering gateway that only
by tancop 13d ago
You don't need a full air gap. Set up a microVM with network access limited to local network and send all package requests through a filtering gateway that only allows normal download endpoints. Or self host a big collection of popular packages if you need extra security.
- amouat 13d agoIsn't that exactly what they did? The bots could only access the jfrog instance, so they hacked jfrog?
- exfalso 13d agoNo that's not what they did, they exposed jfrog raw. It would have been so extremely simple to gate services they need the llm to access... I mean, jfrog was not written with this kind of threat model in mind, and neither were a lot of other tools
- amouat 13d agoRight, you mean it didn't go through a gateway? But would that actually have helped? The requests all went through jfrog didn't they? I guess it depends on the level of filtering at the gateway? Whilst it might not be JFrog's threat model, I wouldn't assume it can be used as a full internet proxy. I don't really mean to defend OpenAI here, but they did make some attempts at sandboxing. Although it does seem that they didn't really know what they were doing.
- exfalso 12d agoIt would have been a case of isolating exactly what functionality is needed and wiring that up with the actual requests. Not like a full pass-through proxy. This is what we've been doing in our company as well
- zahlman 13d ago> jfrog was not written with this kind of threat model in mind, and neither were a lot of other tools And we don't just magically know all the consequences of that. Which is exactly why we do need full, physical air gapping. (Which, yes, would also include self-hosting a mirror of the package repo, if the point of the simulation is to see what's possible with the real package repo.)