26 ms·

It's a zero day in some caching proxy who may not have had that threat model in mind. I guess its primary purpose is caching packages, not restricting internet

by mr_mitm 2mo ago

It's a zero day in some caching proxy who may not have had that threat model in mind. I guess its primary purpose is caching packages, not restricting internet access. That's a far cry from finding a zero day in a hypervisor or even Docker, which OpenAI conveniently left out in their first statement by simply calling it a "sandbox".

0xDEAFBEAD 2mo ago
I can't say for sure, but intuitively this type of vulnerability seems like it could be handy for an attacker trying to move through a target network? In any case, JFrog seems to be taking the situation quite seriously https://jfrog.com/blog/jfrog-and-openai-collaboration-on-zero-day-security-findings/ https://jfrog.com/blog/jfrog-and-openai-collaboration-on-zer...
justincormack 2mo ago
That is the threat model, that is supposed to be safe isolated access in a vpc that isolated applications can access but it has external access.
bri3d 2mo ago
> It's a zero day in some caching proxy who may not have had that threat model in mind. I guess its primary purpose is caching packages, not restricting internet access. In many if not most environments where I have seen these used, they are used to bridge an access boundary and are absolutely security critical. Frequently (and probably in this application, too), they are used for security enforcement in an architecture where CI doesn't have Internet access, but does need to download packages. This is a pretty big deal for a lot of big companies; historically they have relied on stuff like package proxies to help protect them from supply chain compromises like post-install script exploits by preventing CI from being able to detonate an arbitrary Internet payload; if a supply-chain worm were to incorporate this exploit, it would be a lot scarier and more potent. Actually, from the supply-chain worm standpoint, this is arguably a bigger finding than a Docker escape - I suspect we can look forward to more shenanigans in this space coming soon.

by mr_mitm 2mo ago

0xDEAFBEAD 2mo ago

I can't say for sure, but intuitively this type of vulnerability seems like it could be handy for an attacker trying to move through a target network? In any case, JFrog seems to be taking the situation quite seriously https://jfrog.com/blog/jfrog-and-openai-collaboration-on-zero-day-security-findings/ https://jfrog.com/blog/jfrog-and-openai-collaboration-on-zer...

justincormack 2mo ago

That is the threat model, that is supposed to be safe isolated access in a vpc that isolated applications can access but it has external access.

bri3d 2mo ago

> It's a zero day in some caching proxy who may not have had that threat model in mind. I guess its primary purpose is caching packages, not restricting internet access. In many if not most environments where I have seen these used, they are used to bridge an access boundary and are absolutely security critical. Frequently (and probably in this application, too), they are used for security enforcement in an architecture where CI doesn't have Internet access, but does need to download packages. This is a pretty big deal for a lot of big companies; historically they have relied on stuff like package proxies to help protect them from supply chain compromises like post-install script exploits by preventing CI from being able to detonate an arbitrary Internet payload; if a supply-chain worm were to incorporate this exploit, it would be a lot scarier and more potent. Actually, from the supply-chain worm standpoint, this is arguably a bigger finding than a Docker escape - I suspect we can look forward to more shenanigans in this space coming soon.