alt Hacker NewsI expect they have root on their machines so they can install packages etc.
The containers are then firewalled at the network level: they are only allowed to talk to one IP, which is another server that runs an HTTP/HTTPS proxy which controls what HTTP verbs they can use.
Turns out that proxy is configured with some additional rules, like allowing more verbs to that Azure blob domain.
The failure here is in the proxy configuration. Giving agents root in a container feels safe to me, provided that container is properly network isolated (which this one is not thanks to the loose proxy.)
OpenAI also need to be VERY confident that there are no container escapes, which is a high bar given how good these models are at finding new zero-days!
Replies
Container escapes can however be quite easy... There are tons of known exploits. Containers are not secure in the first place. In any case even if you're using VMs or bare metal, it is all for moot if you have poor networking set up like in this case, because escaping is not the hard part. An attacker doesn't really need to escape if they can scan your whole network and call other endpoints etc. like in this case.
I think the proxy must be on the same machine, otherwise why are they suggesting editing the /etc/hosts file?
If the whole point of these models is they can find security vulnerabilities and zero days then how is it going to be possible to contain them?
But that wouldn't work, right? If the proxy is on another server then editing their own /etc/hosts wouldn't change the proxy's behavior. So the proxy has to be colocated and reading the same /etc/hosts that they're editing. But that would mean it's running within the same userns/pid domain as the agents, so at that point they don't even need to edit /etc/hosts, they could just use the network directly.
And the agent says ABS is not handled by the proxy, it's listed in NO_PROXY so they should connect directly.
At any rate it's easy to let agents install packages without giving them root. I use a small SUID binary that just invokes `apt install` after checking that the given argument isn't a file path, which I think is sufficient (using sudo to whitelist a prefix allows an agent to create a .deb themselves and then install it directly via apt, similar issues exist for other package managers).