4 ms·

Yes but slirp isn't used in a production grade setup. It's more of a simple slow default that's guarantees to work, so it's used mostly in development setups.

sansnomme 7y ago
Why would it compromise the hypervisor though?
- geofft 7y ago
  There's no separate "hypervisor" component. QEMU itself is the hypervisor. That is, QEMU is a regular computer program whose functionality is to emulate a machine; that emulated machine is called a virtual machine. QEMU itself runs on a regular computer OS like Linux. (QEMU with hardware acceleration is a perfectly good and quite common production-grade virtualization setup.) All the code described here is part of QEMU itself, not part of the virtualized OS running inside QEMU. If a VM running inside QEMU is able to compromise QEMU's code, it then runs with the privileges of QEMU on the host. The host, the regular OS running QEMU, is colloquially called "the hypervisor." And in most production virtualization setups, there is nothing of interest on the host other than some QEMU processes itself, i.e., anything valuable on the host is perfectly well accessible to QEMU, and therefore to malicious code that has taken over the QEMU process.
  - jsolson 7y ago
    It's quite reasonable to distinguish QEMU from the hypervisor: QEMU typically runs with strictly lower privileges. The "hardware acceleration" that helps QEMU emulate a computer operates in root VMX and non-root VMX (when actually executing guest instructions) modes. When operating in root VMX mode as a supervisor, it has approximately the highest privileges in the system (ignoring SMM), as it is operating in host ring 0. QEMU runs in host ring 3, making it a typical user mode process. If you manage to compromise QEMU (and only QEMU), you have only escaped into host user mode. In that case you haven't compromised the hypervisor, merely the virtual machine monitor. If, on the other hand, you manage to compromise KVM (or vhost) you could reasonably claim to have actually compromised the hypervisor. Type 2 hypervisors make this generally much uglier than type 1, but it's reasonable to say that the hypervisor in a type 2 deployment is limited to the kernel component rather than the user-mode VMM.
    - person_of_color 7y ago
      Where do you get this type of academic education of virtualization techniques?
      - RaitoBezarius 7y ago
        Depends on your country, but I suppose it has to do with theoretical computer science at the master level, you can see a lot of academic content around this (in Paris, France for example): https://wikimpri.dptinfo.ens-cachan.fr/doku.php https://wikimpri.dptinfo.ens-cachan.fr/doku.php (yes, HTTPS is broken…)
      - jsolson 7y ago
        Some of it is academic study (BS and MS at Georgia Tech) -- that helped with the theory and a bit of the breadth. That said, most of what I know of modern virtualization was more or less "on the job" from working on Google Compute Engine. Lots of practical experience understanding virtualization boundaries, and really really enormous access to historical domain experts in the space.
    - rasz 7y ago
      > it has approximately the highest privileges in the system (ignoring SMM) and MINIX in case of Intel :-)
  - bonzini 7y ago
    > anything valuable on the host is perfectly well accessible to QEMU In a well configured KVM instance QEMU obeys the principle of least privilege as much as possible, that is it can only access the resources it needs to do its job. In practical terms, this means QEMU is confined (via SELinux, cgroups, Unix permissions, seccomp) to only access resources for the VM it is running; taking over QEMU does not give you access to "anything valuable on the host". Of course, having remote code execution in QEMU is awful; it can be a base for exploiting a kernel vulnerability to get root access. Luckily this bug would not be exploitable in a production setting.
    - zurn 7y ago
      I think the intersection of conigurations where QEMU is using the SLiRP networking and where it's carefully configured to use the (non-default) sandboxing is pretty small. The sandboxing configs are typically associated with use of libvirt where you'll probably be using tun/tap or some other non-slirp kind of networking.
      - bonzini 7y ago
        Exactly, this is why this bug is unlikely to be exploitable in production (OpenStack for example only runs QEMU via Libvirt).
    - geofft 7y ago
      In a production system, it's highly unlikely that there is anything on the host besides the VM. You're not running qemu on one core and an unvirtualized database on another. Amazon is not running an S3 file server on the same physical machine that's being an EC2 host. The only valuable thing is other VMs. And I think that there is no common configuration of OpenStack or libvirt that assigns unique access control labels per VM. Every qemu runs with the same privileges, ergo one exploited qemu can laterally attack another. (But maybe there's something nifty I'm missing?) (Agree that for the use case of desktop virtualization, a good SELinux config can keep it from accessing your browser cookies.)
      - 7y ago
bonzini 7y ago
Note that since the last version of QEMU (4.1, released a few days ago) slirp has been moved out into a separate library hosted at https://gitlab.freedesktop.org/slirp/libslirp https://gitlab.freedesktop.org/slirp/libslirp. There is interest in using it in container runtimes as well, and hopefully this will give slirp more love. It's very old code that most QEMU developers wouldn't have touched with a ten-foot pole...
- rtpg 7y ago
  >Testing > Unfortunately, there are no automated tests available. > You may run QEMU -net user linked with your development version. Not trying to shame anyone here, but I do think that this would be a good entry point for anyone trying to help this project out. Hell, this might be a fun little target for property testing or other kinds of generative testing

sansnomme 7y ago

Why would it compromise the hypervisor though?

geofft 7y ago
There's no separate "hypervisor" component. QEMU itself is the hypervisor. That is, QEMU is a regular computer program whose functionality is to emulate a machine; that emulated machine is called a virtual machine. QEMU itself runs on a regular computer OS like Linux. (QEMU with hardware acceleration is a perfectly good and quite common production-grade virtualization setup.) All the code described here is part of QEMU itself, not part of the virtualized OS running inside QEMU. If a VM running inside QEMU is able to compromise QEMU's code, it then runs with the privileges of QEMU on the host. The host, the regular OS running QEMU, is colloquially called "the hypervisor." And in most production virtualization setups, there is nothing of interest on the host other than some QEMU processes itself, i.e., anything valuable on the host is perfectly well accessible to QEMU, and therefore to malicious code that has taken over the QEMU process.
- jsolson 7y ago
  It's quite reasonable to distinguish QEMU from the hypervisor: QEMU typically runs with strictly lower privileges. The "hardware acceleration" that helps QEMU emulate a computer operates in root VMX and non-root VMX (when actually executing guest instructions) modes. When operating in root VMX mode as a supervisor, it has approximately the highest privileges in the system (ignoring SMM), as it is operating in host ring 0. QEMU runs in host ring 3, making it a typical user mode process. If you manage to compromise QEMU (and only QEMU), you have only escaped into host user mode. In that case you haven't compromised the hypervisor, merely the virtual machine monitor. If, on the other hand, you manage to compromise KVM (or vhost) you could reasonably claim to have actually compromised the hypervisor. Type 2 hypervisors make this generally much uglier than type 1, but it's reasonable to say that the hypervisor in a type 2 deployment is limited to the kernel component rather than the user-mode VMM.
  - person_of_color 7y ago
    Where do you get this type of academic education of virtualization techniques?
    - RaitoBezarius 7y ago
      Depends on your country, but I suppose it has to do with theoretical computer science at the master level, you can see a lot of academic content around this (in Paris, France for example): https://wikimpri.dptinfo.ens-cachan.fr/doku.php https://wikimpri.dptinfo.ens-cachan.fr/doku.php (yes, HTTPS is broken…)
    - jsolson 7y ago
      Some of it is academic study (BS and MS at Georgia Tech) -- that helped with the theory and a bit of the breadth. That said, most of what I know of modern virtualization was more or less "on the job" from working on Google Compute Engine. Lots of practical experience understanding virtualization boundaries, and really really enormous access to historical domain experts in the space.
  - rasz 7y ago
    > it has approximately the highest privileges in the system (ignoring SMM) and MINIX in case of Intel :-)
- bonzini 7y ago
  > anything valuable on the host is perfectly well accessible to QEMU In a well configured KVM instance QEMU obeys the principle of least privilege as much as possible, that is it can only access the resources it needs to do its job. In practical terms, this means QEMU is confined (via SELinux, cgroups, Unix permissions, seccomp) to only access resources for the VM it is running; taking over QEMU does not give you access to "anything valuable on the host". Of course, having remote code execution in QEMU is awful; it can be a base for exploiting a kernel vulnerability to get root access. Luckily this bug would not be exploitable in a production setting.
  - zurn 7y ago
    I think the intersection of conigurations where QEMU is using the SLiRP networking and where it's carefully configured to use the (non-default) sandboxing is pretty small. The sandboxing configs are typically associated with use of libvirt where you'll probably be using tun/tap or some other non-slirp kind of networking.
    - bonzini 7y ago
      Exactly, this is why this bug is unlikely to be exploitable in production (OpenStack for example only runs QEMU via Libvirt).
  - geofft 7y ago
    In a production system, it's highly unlikely that there is anything on the host besides the VM. You're not running qemu on one core and an unvirtualized database on another. Amazon is not running an S3 file server on the same physical machine that's being an EC2 host. The only valuable thing is other VMs. And I think that there is no common configuration of OpenStack or libvirt that assigns unique access control labels per VM. Every qemu runs with the same privileges, ergo one exploited qemu can laterally attack another. (But maybe there's something nifty I'm missing?) (Agree that for the use case of desktop virtualization, a good SELinux config can keep it from accessing your browser cookies.)
    - 7y ago

bonzini 7y ago

Note that since the last version of QEMU (4.1, released a few days ago) slirp has been moved out into a separate library hosted at https://gitlab.freedesktop.org/slirp/libslirp https://gitlab.freedesktop.org/slirp/libslirp. There is interest in using it in container runtimes as well, and hopefully this will give slirp more love. It's very old code that most QEMU developers wouldn't have touched with a ten-foot pole...

rtpg 7y ago
>Testing > Unfortunately, there are no automated tests available. > You may run QEMU -net user linked with your development version. Not trying to shame anyone here, but I do think that this would be a good entry point for anyone trying to help this project out. Hell, this might be a fun little target for property testing or other kinds of generative testing