6 ms·

Sigh. 1. I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. 2. The write-to-RO-page-cache primitive STILL W

by amluto 6mo ago

Sigh. 1. I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. 2. The write-to-RO-page-cache primitive STILL WORKED! It’s just that the particular exploit used had no meaningful effect in the already-root-in-a-container context. If you think you are safe, you’re probably wrong. All you need to make a new exploit is an fd representing something that you aren’t supposed to be able to write. This likely includes CoW things where you are supposed to be able to write after CoW but you aren’t supposed to be able to write to the source. So: - Are you using these containers with a common image or even a common layer in an image to isolate dangerous workloads from each other. Oops, they can modify the image layers and corrupt each other. There goes any sort of cross-tenant isolation. - What if you get an fd backed by the zero page and write to it? This can’t result in anything that the administrator would approve of. - What if you ro-bind-mount something in? It’s not ro any more.

hlieberman 6mo ago
In fact, the authors specifically say on the very first line of their website that the copy/fail primitive can be used as a container escape. The entire premise of this article is flawed and irresponsible.
- deleted 6mo ago
  [deleted]
- eqvinox 6mo ago
  AIUI they haven't shown a container escape and are just claiming it so far. Or did I miss something?
  - mjmas 6mo ago
    Having write access on anything you can read should be enough if libraries or binaries are shared (read-only) between the host and container.
    - eqvinox 6mo ago
      > if libraries or binaries are shared (read-only) between the host and container. Yeah, exactly - that's a pretty big "if", and not how a lot of container automation does things. In particular you'd need to hit the base system, it's no help at all if some application files that the host does nothing with can be hit.
  - angry_octet 6mo ago
    It's not hard to see ways to escape the container with a cache write primative. I suspect the copy.fail team have held back on releasing a POC because of the disruption it could cause.
    - eqvinox 5mo ago
      It's not a cache write primitive though; it's a write-to-readable-mappings primitive. At least the way I understood it is, you need to be able to get a (read) file descriptor to the target in order to throw it into the splice() syscall. Now, there are some "funky" no-fs things that could be opened and are mmap'able/spliceable (some stuff in /proc/*, no idea what exactly though), but it's not immediately obvious to me how this is a generic container escape.
dwroberts 6mo ago
There is an addendum at the bottom where they admit the page corruption is still problematic even with rootless podman. Although using this to justify their migration to micro-VMs is very strange to me. Sure for this CVE it would have been better, but surely for a future attack it could hit a component shared across VMs but not containers? Are people really choosing technology based on CVE-of-the-week?
- anygivnthursday 6mo ago
  Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance.
  - ButlerianJihad 6mo ago
    Containers are a convenience boundary and they increase complexity of your risk assessments. It is easy for security scanners to scan a Linux system, but will they inspect your containers, and snaps, and flatpaks, and VMs? It is easy for DevOps to ssh into your Linux server, but can they also get logged in to each container, and do useful things? Your patches and all dependencies are up-to-date on your server, but those containers are still dragging around legacy dependencies, by design. Is your backup system aware of containers and capable of creating backup images or files, that are suitable for restoring back to service?
    - necovek 6mo ago
      Security scanners already support most container and VM image formats in widespread use. Does this increase complexity? Yes, it does. Is it worth the cost? Depends on each individual case IMO.
      - firesteelrain 6mo ago
        You need a tool like Anchore and PrismaCloud to scan the container images then monitor them in runtime with PrismaCloud. Trellix can “scan” however most people turn off or exclude container directories on the host because it can interfere with the running container.
raesene9 6mo ago
I've not looked for podman but moby/docker I believe does now block this https://github.com/moby/profiles/commit/7158007a83005b14a24fb7a833e80123bf406e9d https://github.com/moby/profiles/commit/7158007a83005b14a24f...
fguerraz 6mo ago
I just contributed this [1] which does what you want for seccomp. Well, not by default, but profiling is now effective against this attack. Oh, an this [2] just happened [1] https://github.com/containers/oci-seccomp-bpf-hook/pull/209 https://github.com/containers/oci-seccomp-bpf-hook/pull/209 [2] https://github.com/moby/moby/pull/52501 https://github.com/moby/moby/pull/52501
- Jasper_ 6mo ago
  Blanket blocking socketcall() caused regressions for all 32-bit applications trying to make sockets. In theory, glibc disables socketcall when running on kernel version >= 4.3. In practice, Debian/Fedora/Ubuntu all set glibc's "expected kernel version" to 3.2, so socketcall() is still used on most 32-bit glibc binaries shipped. https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/sysdeps/linux.mk#L4 https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/... https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_436 https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glib...
  - fguerraz 6mo ago
    That’s… great. But who runs containerised 32 bit applications?
jeroenhd 6mo ago
> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. I see a lot of projects blocking those sockets in containers as a response to this exploit, but it seems rather strange to me. We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? It's a rather weird default to use. It's not like we're mass-disabling kernel modules everywhere every time someone discovers an EoP bug, do we? Did we blacklist OpenSSL's binaries after Heartbleed? I suppose it makes sense as a default on vulnerable kernels (though people running vulnerable kernels should put effort into patching rather than workarounds in my opinion), but these defaults are going to be around ten years from now when copy.fail is a distant memory.
- nubinetwork 6mo ago
  > We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? To my knowledge, not many things were using the in-kernel code anyways, the recommended way is to use userland tools... It's optional for openssl, systemd apparently needs it, but deleting the module from one of my systems didn't cause any issues. /shrug
  - PunchyHamster 6mo ago
    I haven't had it loaded on 100s of servers ranging kernel version from 5.10 to 6.14. The use is just that low
- e12e 6mo ago
  In fairness, after heartbleed - there was quite a push to move away from openSSL - like Google's boring ssl, openbsd libressl and Mozilla/nss or gnutls - but the alternative here would be moving to a different kernel, like freebsd or open Solaris/Illumos ...
  - PunchyHamster 6mo ago
    that's just moving to kernel that had 1000x less eyes on it. Yeah sure it will have less exploits but purely because nobody bothers to look when there are much juicer targets on Linux. But I am disappointed that we still don't have clear OpenSSL successor, there is nothing to be salvaged from this mess of a project
PunchyHamster 6mo ago
> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. there is no reason it would be default policy. Else might as well block every socket and just multiplex everything on stdin/out
- cduzz 6mo ago
  I'd have guessed that the default paranoia-first policy would be "drop everything; verify what you need" which would include AF_ALG. share and enjoy!
  - tremon 6mo ago
    How do you propose to implement that "drop everything except what you need" policy? Do your containers come with a detailed list of which OS services and syscalls are required? I think your idea has the same issue as what held back the adoption of selinux: many developers think that having to enumerate their application's behaviour like that is an undue burden. A compounding issue is that using AF_ALG doesn't require a separate syscall: it's just using SYS_socket with the first argument set to 38. Your container behaviour specification needs to be specific enough to not only enumerate allowed syscalls, but the allowed values for each syscall parameter.
    - cduzz 6mo ago
      There are those who are paranoid and those who are expedient. If you're truly paranoid, you spin up the thing you want to run, measure what it does, and open the holes to allow it to do what it needs to. It's tedious and sometimes error-prone, but in some environments it is necessary. In the vast majority of the world, you set permissions to what's reasonable and trust that most of the time things will work out pretty well and have a plan for if you need to fix things on the fly. I personally am not terribly paranoid, but I've worked places where we had to be pretty paranoid (shared hosting).
- SV_BubbleTime 6mo ago
  >might as well block every socket and just multiplex everything on stdin/out You may be on to something…

by amluto 6mo ago

hlieberman 6mo ago

In fact, the authors specifically say on the very first line of their website that the copy/fail primitive can be used as a container escape. The entire premise of this article is flawed and irresponsible.

deleted 6mo ago
[deleted]
eqvinox 6mo ago
AIUI they haven't shown a container escape and are just claiming it so far. Or did I miss something?
- mjmas 6mo ago
  Having write access on anything you can read should be enough if libraries or binaries are shared (read-only) between the host and container.
  - eqvinox 6mo ago
    > if libraries or binaries are shared (read-only) between the host and container. Yeah, exactly - that's a pretty big "if", and not how a lot of container automation does things. In particular you'd need to hit the base system, it's no help at all if some application files that the host does nothing with can be hit.
- angry_octet 6mo ago
  It's not hard to see ways to escape the container with a cache write primative. I suspect the copy.fail team have held back on releasing a POC because of the disruption it could cause.
  - eqvinox 5mo ago
    It's not a cache write primitive though; it's a write-to-readable-mappings primitive. At least the way I understood it is, you need to be able to get a (read) file descriptor to the target in order to throw it into the splice() syscall. Now, there are some "funky" no-fs things that could be opened and are mmap'able/spliceable (some stuff in /proc/*, no idea what exactly though), but it's not immediately obvious to me how this is a generic container escape.

dwroberts 6mo ago

There is an addendum at the bottom where they admit the page corruption is still problematic even with rootless podman. Although using this to justify their migration to micro-VMs is very strange to me. Sure for this CVE it would have been better, but surely for a future attack it could hit a component shared across VMs but not containers? Are people really choosing technology based on CVE-of-the-week?

anygivnthursday 6mo ago
Containers were never a security boundary. VMs have better isolation, which is why people choose them for security. Containers are convenience and usually have better performance.
- ButlerianJihad 6mo ago
  Containers are a convenience boundary and they increase complexity of your risk assessments. It is easy for security scanners to scan a Linux system, but will they inspect your containers, and snaps, and flatpaks, and VMs? It is easy for DevOps to ssh into your Linux server, but can they also get logged in to each container, and do useful things? Your patches and all dependencies are up-to-date on your server, but those containers are still dragging around legacy dependencies, by design. Is your backup system aware of containers and capable of creating backup images or files, that are suitable for restoring back to service?
  - necovek 6mo ago
    Security scanners already support most container and VM image formats in widespread use. Does this increase complexity? Yes, it does. Is it worth the cost? Depends on each individual case IMO.
    - firesteelrain 6mo ago
      You need a tool like Anchore and PrismaCloud to scan the container images then monitor them in runtime with PrismaCloud. Trellix can “scan” however most people turn off or exclude container directories on the host because it can interfere with the running container.

raesene9 6mo ago

I've not looked for podman but moby/docker I believe does now block this https://github.com/moby/profiles/commit/7158007a83005b14a24fb7a833e80123bf406e9d https://github.com/moby/profiles/commit/7158007a83005b14a24f...

fguerraz 6mo ago

I just contributed this [1] which does what you want for seccomp. Well, not by default, but profiling is now effective against this attack. Oh, an this [2] just happened [1] https://github.com/containers/oci-seccomp-bpf-hook/pull/209 https://github.com/containers/oci-seccomp-bpf-hook/pull/209 [2] https://github.com/moby/moby/pull/52501 https://github.com/moby/moby/pull/52501

Jasper_ 6mo ago
Blanket blocking socketcall() caused regressions for all 32-bit applications trying to make sockets. In theory, glibc disables socketcall when running on kernel version >= 4.3. In practice, Debian/Fedora/Ubuntu all set glibc's "expected kernel version" to 3.2, so socketcall() is still used on most 32-bit glibc binaries shipped. https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/sysdeps/linux.mk#L4 https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/... https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_436 https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glib...
- fguerraz 6mo ago
  That’s… great. But who runs containerised 32 bit applications?

jeroenhd 6mo ago

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. I see a lot of projects blocking those sockets in containers as a response to this exploit, but it seems rather strange to me. We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? It's a rather weird default to use. It's not like we're mass-disabling kernel modules everywhere every time someone discovers an EoP bug, do we? Did we blacklist OpenSSL's binaries after Heartbleed? I suppose it makes sense as a default on vulnerable kernels (though people running vulnerable kernels should put effort into patching rather than workarounds in my opinion), but these defaults are going to be around ten years from now when copy.fail is a distant memory.

nubinetwork 6mo ago
> We're disabling a cryptographic performance enhancement feature entirely because there was a security bug in them that one time? To my knowledge, not many things were using the in-kernel code anyways, the recommended way is to use userland tools... It's optional for openssl, systemd apparently needs it, but deleting the module from one of my systems didn't cause any issues. /shrug
- PunchyHamster 6mo ago
  I haven't had it loaded on 100s of servers ranging kernel version from 5.10 to 6.14. The use is just that low
e12e 6mo ago
In fairness, after heartbleed - there was quite a push to move away from openSSL - like Google's boring ssl, openbsd libressl and Mozilla/nss or gnutls - but the alternative here would be moving to a different kernel, like freebsd or open Solaris/Illumos ...
- PunchyHamster 6mo ago
  that's just moving to kernel that had 1000x less eyes on it. Yeah sure it will have less exploits but purely because nobody bothers to look when there are much juicer targets on Linux. But I am disappointed that we still don't have clear OpenSSL successor, there is nothing to be salvaged from this mess of a project

PunchyHamster 6mo ago

> I would hope the default seccomp policy blocks AF_ALG in these containers. I bet it doesn’t. Oh well. there is no reason it would be default policy. Else might as well block every socket and just multiplex everything on stdin/out

cduzz 6mo ago
I'd have guessed that the default paranoia-first policy would be "drop everything; verify what you need" which would include AF_ALG. share and enjoy!
- tremon 6mo ago
  How do you propose to implement that "drop everything except what you need" policy? Do your containers come with a detailed list of which OS services and syscalls are required? I think your idea has the same issue as what held back the adoption of selinux: many developers think that having to enumerate their application's behaviour like that is an undue burden. A compounding issue is that using AF_ALG doesn't require a separate syscall: it's just using SYS_socket with the first argument set to 38. Your container behaviour specification needs to be specific enough to not only enumerate allowed syscalls, but the allowed values for each syscall parameter.
  - cduzz 6mo ago
    There are those who are paranoid and those who are expedient. If you're truly paranoid, you spin up the thing you want to run, measure what it does, and open the holes to allow it to do what it needs to. It's tedious and sometimes error-prone, but in some environments it is necessary. In the vast majority of the world, you set permissions to what's reasonable and trust that most of the time things will work out pretty well and have a plan for if you need to fix things on the fly. I personally am not terribly paranoid, but I've worked places where we had to be pretty paranoid (shared hosting).
SV_BubbleTime 6mo ago
>might as well block every socket and just multiplex everything on stdin/out You may be on to something…