6 ms·

QEMU: user-to-root privesc inside VM via bad translation caching

99 points by webaholic 10y ago

omribahumi 10y ago
> To be clear: As far as I know, this bug only affects the TCG mode (without hardware acceleration), not KVM VMs or so. I wonder what's the reach of that bug.
- Confiks 10y ago
  As the bug seems to rely on a maximum instruction length that is present in hardware x86 but not in QEMU's x86, the reach of this particular bug seems to be just the software emulated mode.
  - omribahumi 10y ago
    Yes, I get that. I was wondering how widely used is qemu in x86 software mode
    - Confiks 10y ago
      It might be used for special applications, but not for your typical server that is connected to the internet, simply because it's horribly slow compared to the virtualization support (VT-x / AMD-V) most modern CPUs offer since at least 2010.
      - omribahumi 10y ago
        Right, if you're running on x86 hardware. The use case is probably non-x86 hardware running x86 VMs. For example, I remember using qemu to emulate RPi with ARM software emulation on my x86 machine.
- bonzini 10y ago
  Zero. TCG is not considered secure/trusted by any means by the QEMU team, unlike KVM or Xen. It has never received a serious security audit.
  - omribahumi 10y ago
    That doesn't mean people don't use it. Is what you're saying here documented anywhere?
    - pm215 10y ago
      It is documented here, but you're right that ideally we could mention it somewhere more prominent. http://wiki.qemu-project.org/SecurityProcess#How_impact_and_severity_of_a_bug_is_decided http://wiki.qemu-project.org/SecurityProcess#How_impact_and_...
      - robryk 10y ago
        Is this the correct link? I can find nothing about TCG nor about "tiny code generator" there. It would be nice to warn about lack of security properties of TCG in some of these places: http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/README;hb=HEAD http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/R... http://wiki.qemu-project.org/Documentation/TCG http://wiki.qemu-project.org/Documentation/TCG
        pm215 10y ago
        It's the bit where it says 'is it used in conjunction with a hypervisor?'. That's how we define the use cases that count as defendable against malicious guests. This covers more than just the TCG cpu emulation because it also means that any device model that can only be used with an emulated CPU is also out of scope for CVEs and hasn't been audited to confirm it has no VM-escape bugs. So the internal documentation of TCG itself isn't really the right place to document this I think.
        10y ago
tyingq 10y ago
"However, while real X86 processors have a maximum instruction length of 15 bytes, QEMU's instruction decoder for X86 does not place any limit on the instruction and length or the number of instruction prefixes." Interesting, and not your usual type of exploit. Guessing this isn't one that will have the Rust crowd doling out "told ya so" :). Logic error only. No buffer overflow, not much strong types do for you, etc.
- quotemstr 10y ago
  Well, look on the bright side: once we eliminate the boring old memory safety bugs, and the XSS, and the SQL injection, the exploits that remain will at least be interesting.
  - orblivion 10y ago
    And they'll have time to deal with them.
- deleted 10y ago
  [deleted]
- pjmlp 10y ago
  If we remove memory corruption errors, that it already one less class of errors to worry about. As for the <whatever type safe systems programming language> crowd, these complaints have been done in the past by fairly unknown people like C. A. R. Hoare, Niklaus Wirth, James G. Mitchell, Alan Kay, Luca Cardelli,.... so what do they know about computers.
- hueving 10y ago
  If you really wanted to fish for a "told ya so", someone could just point out that by eliminating all of those other classes of bugs, developers could have spent more time looking for logic errors.
  - nullc 10y ago
    I got that while trolling Rust developers a bit on this point, and had to concede-- it's a fair point. I do think that rust doesn't (yet) have enough affordances for formal verification of algorithmic correctness-- but if you're not chasing memory safety you have more time to deal with other issues.
gbrown_ 10y ago
Not sure why this wasn't duped to https://news.ycombinator.com/item?id=13921305 https://news.ycombinator.com/item?id=13921305
- tomhoward 10y ago
  Dang has addressed this matter several times in the past [1]. The dupe detector is 'deliberately porous' so good stories have multiple chances to get exposure. [1] https://hn.algolia.com/?query=dang%20porous&sort=byPopularity&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=dang%20porous&sort=byPopularit...
  - gbrown_ 10y ago
    Ah interesting didn't know this, thanks.

99 points by webaholic 10y ago

> To be clear: As far as I know, this bug only affects the TCG mode (without hardware acceleration), not KVM VMs or so. I wonder what's the reach of that bug.

Confiks 10y ago
As the bug seems to rely on a maximum instruction length that is present in hardware x86 but not in QEMU's x86, the reach of this particular bug seems to be just the software emulated mode.
- omribahumi 10y ago
  Yes, I get that. I was wondering how widely used is qemu in x86 software mode
  - Confiks 10y ago
    It might be used for special applications, but not for your typical server that is connected to the internet, simply because it's horribly slow compared to the virtualization support (VT-x / AMD-V) most modern CPUs offer since at least 2010.
    - omribahumi 10y ago
      Right, if you're running on x86 hardware. The use case is probably non-x86 hardware running x86 VMs. For example, I remember using qemu to emulate RPi with ARM software emulation on my x86 machine.
bonzini 10y ago
Zero. TCG is not considered secure/trusted by any means by the QEMU team, unlike KVM or Xen. It has never received a serious security audit.
- omribahumi 10y ago
  That doesn't mean people don't use it. Is what you're saying here documented anywhere?
  - pm215 10y ago
    It is documented here, but you're right that ideally we could mention it somewhere more prominent. http://wiki.qemu-project.org/SecurityProcess#How_impact_and_severity_of_a_bug_is_decided http://wiki.qemu-project.org/SecurityProcess#How_impact_and_...
    - robryk 10y ago
      Is this the correct link? I can find nothing about TCG nor about "tiny code generator" there. It would be nice to warn about lack of security properties of TCG in some of these places: http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/README;hb=HEAD http://git.qemu-project.org/?p=qemu.git;a=blob_plain;f=tcg/R... http://wiki.qemu-project.org/Documentation/TCG http://wiki.qemu-project.org/Documentation/TCG
      - pm215 10y ago
        It's the bit where it says 'is it used in conjunction with a hypervisor?'. That's how we define the use cases that count as defendable against malicious guests. This covers more than just the TCG cpu emulation because it also means that any device model that can only be used with an emulated CPU is also out of scope for CVEs and hasn't been audited to confirm it has no VM-escape bugs. So the internal documentation of TCG itself isn't really the right place to document this I think.
        10y ago

tyingq 10y ago

"However, while real X86 processors have a maximum instruction length of 15 bytes, QEMU's instruction decoder for X86 does not place any limit on the instruction and length or the number of instruction prefixes." Interesting, and not your usual type of exploit. Guessing this isn't one that will have the Rust crowd doling out "told ya so" :). Logic error only. No buffer overflow, not much strong types do for you, etc.

quotemstr 10y ago
Well, look on the bright side: once we eliminate the boring old memory safety bugs, and the XSS, and the SQL injection, the exploits that remain will at least be interesting.
- orblivion 10y ago
  And they'll have time to deal with them.
deleted 10y ago
[deleted]
pjmlp 10y ago
If we remove memory corruption errors, that it already one less class of errors to worry about. As for the <whatever type safe systems programming language> crowd, these complaints have been done in the past by fairly unknown people like C. A. R. Hoare, Niklaus Wirth, James G. Mitchell, Alan Kay, Luca Cardelli,.... so what do they know about computers.
hueving 10y ago
If you really wanted to fish for a "told ya so", someone could just point out that by eliminating all of those other classes of bugs, developers could have spent more time looking for logic errors.
- nullc 10y ago
  I got that while trolling Rust developers a bit on this point, and had to concede-- it's a fair point. I do think that rust doesn't (yet) have enough affordances for formal verification of algorithmic correctness-- but if you're not chasing memory safety you have more time to deal with other issues.

gbrown_ 10y ago

Not sure why this wasn't duped to https://news.ycombinator.com/item?id=13921305 https://news.ycombinator.com/item?id=13921305

tomhoward 10y ago
Dang has addressed this matter several times in the past [1]. The dupe detector is 'deliberately porous' so good stories have multiple chances to get exposure. [1] https://hn.algolia.com/?query=dang%20porous&sort=byPopularity&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=dang%20porous&sort=byPopularit...
- gbrown_ 10y ago
  Ah interesting didn't know this, thanks.