Hacker News Reader

Comment by _ink_ | Hacker News Reader

Does secret injection really prevent that the agent send my GitHub key somewhere? If it has access to it via env var, can it not just paste it somewhere?

View on HN

The env var is just a placeholder in the VM, so no real secret is in there.

right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret.

And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it.

Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.

The agent has no access to the secret. It has a placeholder that is replaced at a higher level. When it makes the network request the secret is substituted but that is outside of the caller's worldview.

So what stops it from sending a network request to a git repo that pushes what that placeholder resolves to?

How would that work? You don't control github.com servers so your repo would never see the secret.

edit: You may want to look into tokenizing proxies as the general application of this concept.

Your agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt

It only replaces the token in the HTTP header that is sent to the server. Whatever you wrote in your files isn't touched by the proxy.

It sends a request to requestb.in and reads the public log of the headers. There are ways.

But requestb.in is not api.github.com so the proxy wouldn't replace anything.

Maybe the tokenizing proxy could work both ways? If the agent tries to read secret.txt, it gets back the placeholder.

Couldn't it then just publish the mock in a public place... it would get replaced by the real secret.? How is this prevented

But how? Normally the TLS handshake and encryption/decryption happen in user space. Even the kernel doesn’t know anything about it.

There is a transparent proxy installed (along with the necessary certificates on the VM.) For an example, see https://docs.microsandbox.dev/networking/tls

So, if the program or the proxy solution doesn’t support it, then it doesn’t work? Like with security solutions?

The docs mention it can be bypassed for configured domains.

Yes, I read it. That means that it doesn’t work in those cases. Btw, as a developer it’s very easy to have something like that. It’s not as trivial as it seems at all. I encountered with similar problems all the time, with similar solutions (mainly for security theater reasons) in the past. There are websites which simply doesn’t work if you replace certificates, regardless of browser or CA for example.

Yes, I've worked with people who have run into issues with "security" solutions like ZScaler. I have tried it with some APIs (like GitHub) and it does work. Not to say it will work in your case.

I was just interested how it works, because above it was sold as “it works”, when in reality, “it works*”.

Isn't it that way with most software? "It works", except when it doesn't.

There is a difference between bugs/failures, and false advertisement. The solution used here has well known shortcomings.

All SSL/TLS interception has the shortcoming. In other contexts, that’s a good thing, when certificate pinning works, I mean.

microsandbox is designed to work with most security products. there's a dedicated section for this in the docs that makes this entire process seamless: https://docs.microsandbox.dev/networking/tls#trusting-host-c...

microsandbox maintainer here. the custom certificate is installed in the guest's trusted root CA list, so it should work across any program, except where the program opts to explicitly pin certificates for a destination.

It’s injected into an outbound api call, not into an env var the agent can read.

what's to stop an agent creating an outbound call with the var to a malicious endpoint? (unless you whitelist what it has access to)

You just don't inject the real secret unless hostname/whatever rule matches the request, right? I don't know if that's how this works but it's my assumption.

On the Docker DevRel team... yes! This is it. The secret is injected only into headers in which the hostname matches.

There's also an ability to create kits where you can setup credential injection into other services as well.

At least for gondolin and microsandbox, you bind a specific secret placeholder to the target host. i.e. your GH token is only replaced/injected for calls to api.github.com, not other hosts. And you can set up both with deny-by-default

But then... why is replacent needed at all: just use sone permissions system.

Couldn't the agent post then the key in some public comment?

Only if the replacement is global and not, say, only looking and inserting it into the actual (eg) Authorization header. If something is only transparently altering the Authorization header, then an agent inserting the dummy value somewhere else is totally safe.

For clarity, there is no "search and replace" function going on. It's only setting the header.

The main reason a "proxy-managed" env var is set is because most CLI tools assume if the env var is set, auth is set. If the env var is unset, it will assume auth needs to occur. Fortunately, most don't do a pattern matching on what the value actually is.

The replacement is on a url/host basis.

or an outbound call to a trusted endpoint with the env var in a way that can get exposed to the agent via a subsequent call?

It's possible reflected instances are masked too, like GitHub Actions. But I don't know.

How would that work, exactly? What are you envisioning?

Reply on news.ycombinator.com