If you download a zip file that contains the hidden .git folder, with the config file inside, and open it with an LLM, it can run an arbitrary program, if you ask it to or not. Even if it's not actually a git repository, as long as it has enough to trigger the hooks when you run "git status". That sounds like a massive problem to me
Your threat model is that you give an untrusted .zip archive to an LLM, and it decides to unpack that, then decides to try using it like a git repository because the unpack produced a .git folder?
Yeah, I wouldn't have --dangerously-skip-permissions on for that. I mean, the archive might also contain attempts at prompt injection.
Doesn't require a permissions bypass or a prompt, that's the point. Every agent here ships a workspace trust prompt but the payload fires before it's shown. `--dangerously-skip-permissions` is therefore irrelevant as the permission system never got consulted.
Delivery isn't self-inflicted either. A colleague sends you a zip or a client hands over a codebase. Inspecting `.git/config` before opening a shared project isn't standard practice. Pointing an agent at a project you were sent is what agents are for and exactly why these tools ship a workspace trust prompt. The issue here is that it fires too late.
Using git is not a requirement here. You just need enough of a git folder for a "git status" to trigger running a program, and the "git status" is run automatically by an agent, without you asking it to. You could open any innocuous folder that you have been sent by someone else, and the agent would run the program. At my job, we send clients a folder containing the completed project. If someone was to put in a .git folder with the config option set, not even a full repository, and the client opened it with an agent, then we could have made the client run any command we wanted
Comments
If you download a zip file that contains the hidden .git folder, with the config file inside, and open it with an LLM, it can run an arbitrary program, if you ask it to or not. Even if it's not actually a git repository, as long as it has enough to trigger the hooks when you run "git status". That sounds like a massive problem to me
Your threat model is that you give an untrusted .zip archive to an LLM, and it decides to unpack that, then decides to try using it like a git repository because the unpack produced a .git folder?
Yeah, I wouldn't have --dangerously-skip-permissions on for that. I mean, the archive might also contain attempts at prompt injection.
Doesn't require a permissions bypass or a prompt, that's the point. Every agent here ships a workspace trust prompt but the payload fires before it's shown. `--dangerously-skip-permissions` is therefore irrelevant as the permission system never got consulted.
Delivery isn't self-inflicted either. A colleague sends you a zip or a client hands over a codebase. Inspecting `.git/config` before opening a shared project isn't standard practice. Pointing an agent at a project you were sent is what agents are for and exactly why these tools ship a workspace trust prompt. The issue here is that it fires too late.
You get a folder from someone else. You open your LLM of choice in that folder. You are pwned
Who (1) uses git and (2) passes around folders like that?
This is a PEBKAC thing more than a security issue
Using git is not a requirement here. You just need enough of a git folder for a "git status" to trigger running a program, and the "git status" is run automatically by an agent, without you asking it to. You could open any innocuous folder that you have been sent by someone else, and the agent would run the program. At my job, we send clients a folder containing the completed project. If someone was to put in a .git folder with the config option set, not even a full repository, and the client opened it with an agent, then we could have made the client run any command we wanted