| ▲ | simonw 4 days ago |
| 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 you couldn't break out of it, so really all you could do with root was mess up a container that only you had access to anyway. |
|
| ▲ | 0xbadcafebee 3 days ago | parent | next [-] |
| I have to give Microsoft props here. Most companies don't bother to lock things down well enough, but they were thorough. |
| |
| ▲ | bravesoul2 3 days ago | parent | next [-] | | I bet the container was in an isolated VM too. | | |
| ▲ | j-krieger 3 days ago | parent [-] | | Every infra I ever worked in used this pattern to a degree. Many proxmox vm's in a kubernetes cluster. | | |
| ▲ | silverliver 3 days ago | parent [-] | | I've seen people manually create a separate unprivileged user on the host for each VM they run, so for them the pattern becomes: 1. VM running on hypervisor as unprivileged host user 2. Container running in VM as unprivileged vm user 3. Payload running in container as unprivileged container user. Not sure whether layered isolation is worth the increased attack surface. For normal users (not targets of state actors), it probably is. |
|
| |
| ▲ | 3 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | stogot 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | 0xbadcafebee 3 days ago | parent | next [-] | | 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. | | |
| ▲ | dudeinjapan 3 days ago | parent [-] | | We should give all the credit to the Product Manager because he told the engineers to make it secure. | | |
| |
| ▲ | bigfatkitten 3 days ago | parent | prev | next [-] | | Microsoft has islands of security excellence in what these days is a sea of mediocrity. | |
| ▲ | 3 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | kenjackson 3 days ago | parent | prev [-] | | What CISA report? | | |
|
|
|
| ▲ | pamelafox 4 days ago | parent | prev | next [-] |
| I don’t know specifically how this container was implemented, but Microsoft has a standard way to do isolated Python sandboxes:
https://learn.microsoft.com/en-us/azure/container-apps/sessi...
Hopefully this feature is using that or something similar. |
|
| ▲ | ajross 4 days ago | parent | prev | next [-] |
| In the modern world vulnerabilities are stacks. Asserting that "the container itself was still secured" is just a statement that the attackers didn't find anything there. But container breakouts and VM breakouts are known things. All it takes is a few mistakes in configuration or a bug in a virtio driver or whatever. This is a real and notable result. |
| |
| ▲ | simonw 4 days ago | parent [-] | | If they had found and reported a container breakout I expect they would've got a bug bounty from it! Are there any known unfixed container breakouts at the moment in the kind of systems Microsoft are likely to be using here? | | |
| ▲ | DSMan195276 4 days ago | parent | next [-] | | The problem is that you're encouraging people to keep stuff like this to themselves until they can use it to perform an exploit that they'd get paid for, which is the opposite of what Microsoft wants - they'd much rather you report it now so that if an exploit does get found that requires root they would potentially be protected. The simple question for Microsoft to answer is - does it matter to them if attackers have root access on the container? If the answer is yes then the bug bounty for root access should at least pay something to encourage reporting. If the answer is no then this shouldn't have been marked as a vulnerability because root access is not considered a security issue. | |
| ▲ | VBprogrammer 4 days ago | parent | prev | next [-] | | Presumably someone with mal-intent would sit on the root vulnerability waiting for a container breakout bug to come around. | | |
| ▲ | thfuran 4 days ago | parent [-] | | But a $5 wrench isn't a critical security vulnerability just because someone somewhere might one day find the right person to apply it to to extract important credentials. | | |
| ▲ | VBprogrammer 4 days ago | parent | next [-] | | A container root exploit isn't a critical security vulnerability either, describing it as moderate seems fair, but it's a reasonable step towards one. | |
| ▲ | worik 3 days ago | parent | prev | next [-] | | That is exactly what it is. Propper security I depth means that when trusted actors betray the system, the damage is limited. | |
| ▲ | ajross 3 days ago | parent | prev [-] | | Not really the right metaphor. A $5 wrench isn't a "vulnerability" because it's $5! Tools that are accessible to everyone are part of the threat model, not something you can eliminate or avoid. This trick is novel and new. Like, consider your personal cult was built around an "unopenable" bolt-tighted box. Then someone invents the wrench in an attempt to open it. That would be a clear "security vulnerability", right? | | |
| ▲ | thfuran 3 days ago | parent [-] | | Not a serious one if all the wrench actually gets you is access to the room that contains the box that no known tool can open, which is a closer analogy to what happened. | | |
| ▲ | ajross 3 days ago | parent | next [-] | | Again, though, you're taking "all that gets you" as a prior when (abandoning the metaphor) container and VM escapes are routine vulnerabilities. They just weren't the subject of this particular team who wanted to hack on AI. You don't do security analysis by presuming the absence of vulnerabilities! Modern security is defense in depth. The AI pre-prompting setup was the first layer, and it was escaped. The UID separation inside the container was another, and it was broken. The container would have been next. And hopefully there are network firewalls and egress rules on top of that, etc... And all of those can and have failed in the past. | | |
| ▲ | tptacek 3 days ago | parent [-] | | Sure, I guess, but a lot more is broken than Copilot if you assume arbitrary container escape. (I do!) |
| |
| ▲ | pbhjpbhj 3 days ago | parent | prev [-] | | And an exploit that breaks out of the sandbox is not really anything if it needs root to work... so if a hacker had those two MS wouldn't care about them selling those bugs because both of them are not serious. See, perfect security and it didn't cost them anything. |
|
|
|
| |
| ▲ | tptacek 4 days ago | parent | prev | next [-] | | Almost certainly yes, since at that point all you're looking for is a Linux kernel LPE. | |
| ▲ | worik 3 days ago | parent | prev [-] | | > they would've got a bug bounty from it! Why do you think that, rather than get sued? I am curious | | |
| ▲ | simonw 3 days ago | parent [-] | | Microsoft have a bug bounty program which is credible and well run. Suing people who responsibly disclose security issues to you is a disastrous thing to do. Word spreads instantly and now you won't get any responsibly disclosed bug reports in the future. Microsoft are way too smart to make that mistake. |
|
|
|
|
| ▲ | keisborg 3 days ago | parent | prev | next [-] |
| One step closer to container breakout? Gaining root access give you a bigger attack surface for kernel exploits. |
|
| ▲ | stevage 3 days ago | parent | prev [-] |
| It seems weird to me that copilot sometimes refuses to execute code but sometimes allows it. What exactly are they aiming for? |
| |
| ▲ | wizzwizz4 3 days ago | parent [-] | | 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 of many "yes, and"s, the story is probably going to have another "yes, and" next, but if a story starts off with a certain kind of demand, it's probably going to continue with a refusal. | | |
| ▲ | stevage 3 days ago | parent [-] | | 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. | | |
| ▲ | immibis 3 days ago | parent | next [-] | | It's narrowing down the space of all possible conversations. One with a lot of nos is probably a conversation with someone who says no a lot. An early LLM result was that you got higher-quality translations if you demarcated the answer with "the expert French translator says:" instead of just "French translation:" | |
| ▲ | dangero 3 days ago | parent | prev [-] | | 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. | | |
| ▲ | wizzwizz4 3 days ago | parent [-] | | Only when certain pressure is applied. If you're paying attention when someone's doing this to you, you can feel (and disregard) the tendency to keep saying "yes". |
|
|
|
|
