Live data from Hacker News

How we rooted Copilot

research.eye.security

111–120 of 147 posts

Re: How we rooted Copilot

#111
post #81

It's crazy to me that someone can write a post called "How We Rooted Copilot" when in reality they got root in an ephemeral python sandbox container that was locked down so much that they couldn't do anything. I read "rooted copilot" and I think they got root on a vm that is core to copilot itself. A much more accurate title would be "How We Rooted the Copilot Python Sandbox"

“how we escalated privileges from a regular user to a root user in a completely locked sandbox” pretty much sums it up.

it’s a nothing burger, which actually goes to show just how effective sandboxing is for defense in depth.

Re: How we rooted Copilot

#113

Earlier quoted context omitted.

They're not. It's better to think of Copilot as a collaborative storytelling session with a text autocomplete system, which some other program is rudely hijacking to insert the result of running certain commands. Sometimes the (completion randomly selected from the outputs of the) predictive text model goes "yes, and". Other times, it goes "no, because". As observed in the article, if it's autocompleting the result o…

funny how it sounds kind of the opposite of how people might work. Get enough 'no's from someone and they might finally cave in. get enough 'yes'es and they might get sick of doing everything you ask.

Sales people are specifically trained to manipulate people by asking them questions that they will say ‘yes’ to because once people start to say yes, they tend to continue to say it.

Re: How we rooted Copilot

#114

[dead]

Respectfully, I gave reading this an earnest try, and found it not to make any sense whatsoever. It isn't at all clear to me how your statements logically follow one another. If a friend sent this to me, I would be worried about them.

Re: How we rooted Copilot

#115
post #91

Earlier quoted context omitted.

I would give the one engineer the credit for doing things better, not Microsoft. Microsoft overall culture of security is terrible. Look at the CISA report.

Okay, so I give the team that put this together credit. Hopefully the parent company sees based on this that it's worth letting teams invest more in quality and security work, over features.

We should give all the credit to the Product Manager because he told the engineers to make it secure.

Re: How we rooted Copilot

#116
post #114

[dead]

Respectfully, I gave reading this an earnest try, and found it not to make any sense whatsoever. It isn't at all clear to me how your statements logically follow one another. If a friend sent this to me, I would be worried about them.

After reading their "penetrating" insights about "the weenie" I'm relieved to conclude they're trolling.

Re: How we rooted Copilot

#117
post #10
post #4

> We reported the vulnerability to Microsoft in April and they have since fixed it as a moderate severity vulnerability. As only important and critical vulnerabilities qualify for a bounty award, we did not receive anything, except for an acknowledgement on the Security Researcher Acknowledgments for Microsoft Online Services webpage. I guess it makes sense that a poor little indie company like Microsoft can't pay bu…

The important part: > Now what have we gained with root access to the container? > Absolutely nothing! > We can now use this access to explore parts of the container that were previously inaccessible to us. We explored the filesystem, but there were no files in /root, no interesting logging to find, and a container breakout looked out of the question as every possible known breakout had been patched. I'm sure there a…

IMO if they truly don't consider it dangerous then they shouldn't have considered it a vulnerability at all, just a non-security bug. Labeling it a moderate vuln and not paying just seems like a bad middle ground to me, as though they haven't really decided if restricted root permissions is part of the security model or not.

Re: How we rooted Copilot

#118
post #110

Earlier quoted context omitted.

That repo, and its contributors are MS/Azure employees working on the service for running python code in a container. I don't know why it's under a personal account. Though it says it's a fork from an Office repo that I can't find.

How do you figure? I don’t see anything that suggest they work for ms/azure?

The repo’s owner Employer listed on their profile?

Also you can add .patch to any GitHub commit url and get a git patch file

https://github.com/shivamkm07/code-interpreter/commit/5e282c...

Re: How we rooted Copilot

#119
post #10

Earlier quoted context omitted.

The important part: > Now what have we gained with root access to the container? > Absolutely nothing! > We can now use this access to explore parts of the container that were previously inaccessible to us. We explored the filesystem, but there were no files in /root, no interesting logging to find, and a container breakout looked out of the question as every possible known breakout had been patched. I'm sure there a…

IMO if they truly don't consider it dangerous then they shouldn't have considered it a vulnerability at all, just a non-security bug. Labeling it a moderate vuln and not paying just seems like a bad middle ground to me, as though they haven't really decided if restricted root permissions is part of the security model or not.

Eh, I’m guessing it’s just one of those bugs that have to be categorized as security, but the design assumes that this particular security layer is leaky and is only really there for the experience rather than actual security.

The container is almost certainly running with hypervisor isolation. The trust boundary is with the container. But an LLM is executing arbitrary code in a Jupyter notebook there. It could trash the container, which is not a security issue in itself (again since your boundary is hypervisor anyway) but it’s a pretty shitty experience. Suddenly copilot could trash its container and it no longer can execute code and you’re stuck until whatever session or health check kicks in to give you a new instance. So running LLM generated code/commands in a non-root user makes it easier to have a better experience.

At the same time, you’ll be laughed at if you don’t categorize a root escalation when not expected as a “not a security issue”

Re: How we rooted Copilot

#120
post #8

OK, I think I understand what this is about: the vulnerability that they reported (and Microsoft fixed) is that there was a trick you could use to run your own code with root privileges inside the container - when the system was designed to have you only execute code as a non-root user. It turned out not to really matter, because the container itself was still secured - you couldn't make network requests from it and…

One step closer to container breakout? Gaining root access give you a bigger attack surface for kernel exploits.
Post reply on HN