4 ms·

> I don't know what your point is here. Do you spend a lot of time in your career thinking about hardening your containers against kernel CVEs? Yes, I literall

by t8sr 3y ago

> I don't know what your point is here. Do you spend a lot of time in your career thinking about hardening your containers against kernel CVEs? Yes, I literally led a team of people at a FAANG doing this. You're saying the easiest way to escape a container is a vulnerability normally priced over 1 million USD. I'm saying the easiest way is through one of the million side channels.

deleted 3y ago
[deleted]
insanitybit 3y ago
OK, I apologize if I was coming off as glib or condescending. I will take your input into consideration. I'm not looking to argue, I was just annoyed that I was getting so many of the same comments. It's too early for all of this negativity. If you want to discuss this via an avenue that is not HN I would be open to it, I'm not looking to make enemies here, I'd rather have an earnest conversation with a colleague rather than jumping down their throats because they caught me in the middle of an annoying conversation.
- t8sr 3y ago
  Same, re-reading my replies I realize I phrased things in a stand-offish way. Sorry about that. Thanks for being willing to take a step back. I think possibly we are talking about two different things. IME most instances of exploitation are due to much more rudimentary vulnerabilities. My bias is that, while I did work on mitigations for stuff like Meltdown and Rowhammer, most "code level" memory vulnerabilities were easier to just patch, than to involve my team, so I probably under-estimate their number. Regardless, if I were building computation-as-a-service, 4 types of vulnerability would make me worry about letting multiple containers share a machine: 1. Configuration bugs. It's really easy to give them access to a capability, a mount or some other resource they can use to escape. 2. Kernel bugs in the filesystems, scheduling, virtual memory management (which is different from the C memory model). It's a big surface. As you said, better use a VM. 3. The kernel has straight up vulnerabilities, often related to memory management (use after free, copy too much memory, etc.) 4. The underlying platform has bugs. Some cloud providers don't properly erase physical RAM. x86 doesn't always zero registers. Etc. Most of my experience is in 1, a bit of 2 and mitigation work on 4. The reason I think we're talking past each other a bit is that you're generating CVEs, while I mostly worked on mitigating and detecting/investigating attacks. In my mind, the attacks that are dirt cheap and I see every week are the biggest problem, but if we fix all of those, and the underlying platform gets better, I see that it'll boil down to trusting the kernel doesn't have vulnerabilities.

by t8sr 3y ago

deleted 3y ago

[deleted]

insanitybit 3y ago

OK, I apologize if I was coming off as glib or condescending. I will take your input into consideration. I'm not looking to argue, I was just annoyed that I was getting so many of the same comments. It's too early for all of this negativity. If you want to discuss this via an avenue that is not HN I would be open to it, I'm not looking to make enemies here, I'd rather have an earnest conversation with a colleague rather than jumping down their throats because they caught me in the middle of an annoying conversation.

t8sr 3y ago
Same, re-reading my replies I realize I phrased things in a stand-offish way. Sorry about that. Thanks for being willing to take a step back. I think possibly we are talking about two different things. IME most instances of exploitation are due to much more rudimentary vulnerabilities. My bias is that, while I did work on mitigations for stuff like Meltdown and Rowhammer, most "code level" memory vulnerabilities were easier to just patch, than to involve my team, so I probably under-estimate their number. Regardless, if I were building computation-as-a-service, 4 types of vulnerability would make me worry about letting multiple containers share a machine: 1. Configuration bugs. It's really easy to give them access to a capability, a mount or some other resource they can use to escape. 2. Kernel bugs in the filesystems, scheduling, virtual memory management (which is different from the C memory model). It's a big surface. As you said, better use a VM. 3. The kernel has straight up vulnerabilities, often related to memory management (use after free, copy too much memory, etc.) 4. The underlying platform has bugs. Some cloud providers don't properly erase physical RAM. x86 doesn't always zero registers. Etc. Most of my experience is in 1, a bit of 2 and mitigation work on 4. The reason I think we're talking past each other a bit is that you're generating CVEs, while I mostly worked on mitigating and detecting/investigating attacks. In my mind, the attacks that are dirt cheap and I see every week are the biggest problem, but if we fix all of those, and the underlying platform gets better, I see that it'll boil down to trusting the kernel doesn't have vulnerabilities.