back to article How to get root on a Linux box, step 1: Make four billion system calls

Oh look, it's another Linux kernel bug that allows a local user to escalate themselves to root. In exploiting CVE-2016-0728, discovered by Perception Point, “patience you must have,” because you have to cycle a 32-bit integer in the kernel around to zero. That means making 4,294,967,296 system calls to exploit the …

  1. Grikath

    "if it takes a Core i7 30 minutes to cycle through the values of usage, imagine how long 232 system calls are going to take on an ARM-based phone. "

    Is that with or without considering all the other Always On and Phone Home processes competing for cycles? :P

    1. Preston Munchensonton
      Coat

      I suppose that would depend on whether it's European or African...

      1. Chika

        You expect me to swallow that? ;)

    2. TeeCee Gold badge
      Coat

      On an Android device it'll have crufted and require a reboot well before root pops then.

      Secure By Design!

    3. NoneSuch Silver badge
      Devil

      "imagine how long 232 system calls are going to take on an ARM-based phone."

      Not as long as a NSA Cray supercomputer, I bet.

  2. Anonymous Coward
    Anonymous Coward

    If someone is able to run arbitrary code on your server

    You are already hosed. There will always be some sort of a hole. That this is a kernel hole makes it more interesting, but it is probably not the attack of choice since monitoring might catch the spike in CPU activity it would cause (though it could be patient and do it over a day or two)

    That's why code signing, even though hated by a lot of people, is such a useful defense. It doesn't prevent all attacks, but it does prevent all of the attacks that begin with "step 1) run this arbitrary code on your target" (unless you have step 0 "defeat the code signing checks")

    1. ZSn

      Re: If someone is able to run arbitrary code on your server

      Is code signing really hated by a lot of people? While I don't doubt you, these people need to get out and about a bit more. Code signing is a fairly necessary first step, unless you want to be patient and let it go cold for a month (to let the anti-virus catch up)/or it's been in virustotal's databases as clean for a long time? Or to be really paranoid, all of the above.

      1. agatum

        Re: If someone is able to run arbitrary code on your server

        > Is code signing really hated by a lot of people?

        No hate here whatsoever. From a developers point of view: as long as the process doesn't get in my way no prob. In Xcode's earlier versions, iirc, code signing was a bit pain to set up, at the moment smooth as silk. Ditto for android studio.

        The enhanced security vs the minor trouble: I vote for security any day.

    2. asdf

      Re: If someone is able to run arbitrary code on your server

      >If someone is able to run arbitrary code on your server

      >You are already hosed

      If only there was a multi user operating system shown to stand the test of time against all but a single handful of privilege escalation CVEs. You know like OpenVMS but not completely ruined by HP and Compaq before it. OpenBSD is probably your best bet in the open source world.

      1. Anonymous Coward
        Anonymous Coward

        Re: like OpenVMS but not completely ruined by HP and Compaq

        "like [Open]VMS but not completely ruined by HP and Compaq before it. "

        Did you know that VMS is still around, now in a dedicated organisation out of HP's grubby paws, with many of the original VMS developers back on the team in New England? A supported and tested port to x86-64 is on the way in due course, recognising that IA64 hasn't exactly turned into the Industry Standard 64bit that some at CPQ, HP, Intel (and a couple of others) promised.

        http://vmssoftware.com/ (see also their Facebook page - a Facebook page for VMS, something jars about that concept, but maybe I could get used to it)

        Declaration of disinterest: I have no affiliation with any of the parties above.

        1. asdf

          Re: like OpenVMS but not completely ruined by HP and Compaq

          >Did you know that VMS is still around, now in a dedicated organisation out of HP's grubby paws, with many of the original VMS developers back on the team in New England?

          Hmm have to look into that. I assume they can't use the original VMS code as HP owns that so I would be interested to see how far they get off the ground even with a clean room version before HP tries to nuke them from orbit similar to Google and Oracle over java. I could definitely see an x86_64 version of OpenVMS hitting HP in the pocketbook as they try steer their customers to their inferior pricey shiny new solutions.

          1. Anonymous Coward
            Anonymous Coward

            Re: like OpenVMS but not completely ruined by HP and Compaq

            "I assume they can't use the original VMS code as HP owns that "

            What is it wise people say about assumptions?

            Regardless, your assumption is wrong - the new company has a licence to develop and support VMS and is starting with the existing tried tested and proven VMS sources, and, as I said earlier, many of the former [DEC] VMS team from New England.

            Have a look, see what you find. If you think it might interest a few people, spread the word.

      2. kryptylomese

        Re: If someone is able to run arbitrary code on your server

        OpenBSD has its fair share of vulnerabilities too so is it not just a question of pick your favourite vulnerability?:-

        https://www.cvedetails.com/vulnerability-list/vendor_id-97/Openbsd.html

        Your best bet it to minimise the attack vectors and use good monitoring and patch/update regularly.

        1. asdf

          Re: If someone is able to run arbitrary code on your server

          Yep and a quick perusal shows a large number of those are openssh/*ssl as well as other general *nix software like Xorg, as one would expect and would affect most other *nix systems as well. There have been a few in the OpenBSD kernel as well but far less than the Linux kernel. Still your last sentence is the key regardless of the system.

        2. Anonymous Coward
          Anonymous Coward

          Re: If someone is able to run arbitrary code on your server

          "Your best bet it to minimise the attack vectors..."

          This is so bad I'm in tears! To stay in line with that sentiment helpfulness, another best bet would to turn the fucking thing off!

          Captain, Minimise the Attack Vectors...NOW!

      3. CrazyOldCatMan

        Re: If someone is able to run arbitrary code on your server

        *BSD! *BSD! *BSD!

        :-)

    3. Anonymous Coward
      Windows

      Re: If someone is able to run arbitrary code on your server

      I wonder if Doug is confusing real code signing with NSA/MSFT's "Secure [sic] Boot™" <spits> scam or NSA/Intel Inc.'s b0rken-by-design TXT™ kludge... etc...

    4. Voland's right hand Silver badge

      Re: If someone is able to run arbitrary code on your server

      That's why code signing,

      Code signing is useless on a real world Linux/Unix system. You are not just trying to lock the door after the horse has bolted. You are trying to triple-padlock the barn catflap after the horse has waltzed out through the main door. The main doors have Perl, Python and Shell written on them.

      Any of these will allow you to bypass code signing. You can use any one of them to hit most exploits including exploits which require direct syscall access. Sure, theoretically, you can remove all interpreted languages off a Linux system. In practice - you need to recreate the whole distribution to do so and build an embedded system of your own. You are likely to introduce more new vulnerabilities while doing it.

      1. Vic

        Re: If someone is able to run arbitrary code on your server

        The main doors have Perl, Python and Shell written on them.

        rbash can be very useful here - although it does require you to create a whitelisted set of symlinks to the stuff in /bin, /usr/bin et al.

        Vic.

    5. Destroy All Monsters Silver badge
      Paris Hilton

      Re: If someone is able to run arbitrary code on your server

      If someone is able to run arbitrary code on your server you are already hosed.

      Seriously? Is this a new meme or what?

      Remind me again why multi-user systems were invented in the first place? Yes, OS/360. Multics, that kind of shit.

      So 40 years of work on OS results in "throwing up of hands / tipping the table" in the comment section.

      Might as well shut down this "industry" because it must be a retardcart, really.

      1. Anonymous Coward
        Holmes

        Re: If someone is able to run arbitrary code on your server

        Might as well shut down this "industry" because it must be a retardcart, really.

        About the size of it.

  3. Steve---d

    typo

    "Oh look, it's another Linux kernel bug that allows a local user to escalate themselves to root. In exploiting CVE-2016-0278, discovered by Perception Point..."

    Should be CVE-2016-0728 ... did you type that in by hand?

    1. Will Godfrey Silver badge
      Happy

      Re: typo

      Nono. It was a cunning ruse to prevent people in possession of the computer from accessing root by some means other than typing in the frickin password.

      1. Grikath

        Re: typo

        set up as p4$$w0Rd ... ;)

        1. Tim99 Silver badge

          Re: typo

          @Grikath

          Bugger, I'm going to have to change mine now.

          Perhaps p&55w0Rd will be OK.

          1. Anonymous Coward
            Anonymous Coward

            Re: typo

            I consulted on a SAP deployment for a multi billion dollar defense contractor where the root password was (same on all servers in the entire environment) "P@ssw0rd". It was back in 1998/99, but still...

            1. Naselus

              Re: typo

              ". It was back in 1998/99, but still..."

              Knowing most defense contractors, it still is.

            2. Anonymous Coward
              Anonymous Coward

              Re: typo

              Still is for me [albeit with a counter at the end] - our corporate password policies effectively prevent doing anything sane as there's not a hope in hell of remembering anything with the constant changes & can't-recycle-for-years policies.

  4. Crazy Operations Guy

    CGI

    Would it be possible to exploit this with a CGI on a webserver, like the bash bug from a few months ago?

  5. phil dude
    Linux

    FUD...doesn't work 2 cases...

    I have tried this on two machines (debian kernels 4.1.1 and 4.3.3), both needing root access to read the symbols (commit_creds, and prepare_kernel_cred), compiled and ran for a good while....

    The key counted up to 2147483648 (2^31) and then flipped and counted up again (from -2147483648). It hit some arbitrary positive number and dumped into a shell - with uid 1000 (not root).

    So, no panic here, but waiting on the patch...I would have been more impressed if it has worked..

    Always looking for an easy way to root my tablet without tipping off Google...;-)

    P.

    1. Richard Chirgwin (Written by Reg staff)

      Re: FUD...doesn't work 2 cases...

      Interesting, thanks. - Richard Chirgwin

      1. Anonymous Coward
        WTF?

        Re: FUD...doesn't work 2 cases...

        Didn't work on the Ubuntu 14.04 box I tried it on... and nobody seemed to get it to work at Phoronix either.

        "FUD" +1

    2. notchas

      Re: FUD...doesn't work 2 cases...

      "...then flipped and counted up again (from -2147483648)"

      In an unsigned integer?

      1. phil dude
        Linux

        Re: FUD...doesn't work 2 cases...

        yes....I believe so.

        P.

  6. tony2heads
    Unhappy

    4 billion system calls

    on my phone the battery would be flat before that

  7. tony2heads

    4 billion system calls

    on my phone the battery would be flat before that

    1. Will Godfrey Silver badge
      Happy

      Re: 4 billion system calls

      Wot? Both of them?

      1. Bronek Kozicki
        Happy

        Re: 4 billion system calls

        I'm not surprised that tony2heads needs 2 phones and speaks in duplicate

  8. JeffyPoooh
    Pint

    "...because you have to cycle a 32-bit integer in the kernel around to zero."

    Makes it sound like "you" have to increment it manually. Maybe with a crank handle that needs to be turned. Sounds difficult and exhausting.

    "...because the malware author has to know how to write a loop..." would be more accurate. Conveys an entirely different tone.

    It's the same subtle cognitive bias as when someone claims security because hacking their system is "difficult"; ignoring the entire concept of Script Kiddies.

    1. Naselus

      Re: "...because you have to cycle a 32-bit integer in the kernel around to zero."

      "It's the same subtle cognitive bias as when someone claims security because hacking their system is "difficult"; ignoring the entire concept of Script Kiddies."

      But all security is just making attacks more difficult. There's no such thing as invulnerable security. I can make it so difficult that it takes hundreds of thousands of years to crack the system using present-day hardware... but that'll still be obsolete in five or ten years when a $400 laptop or tablet has more than enough processing power to break it in a couple of days.

      In this case, the means by which you 'turn the crank' are irrelevant. You're still gonna be waiting for a while before root pops either way, and I doubt anyone reading El Reg is dumb enough to assume that hackers do everything manually in human timescales.

      1. Anonymous Coward
        Anonymous Coward

        Re: "...because you have to cycle a 32-bit integer in the kernel around to zero."

        "You're still gonna be waiting for a while before root pops either way, "

        What kind of "a while"?

        Suppose you pick a fast syscall and it takes 1us or so, and then the calling programme continues.

        In my book that's a maximum of an hour or so before a 32bit counter wraps. Which as you already noted may be acceptable for some purposes.

        "There's no such thing as invulnerable security. I can make it so difficult that it takes hundreds of thousands of years to crack the system using present-day hardware... but that'll still be obsolete in five or ten years when a $400 laptop or tablet has more than enough processing power to break it in a couple of days."

        That depends. If all you've got access to for hacking purposes is e.g. an authentication mechanism that always takes (say) 50ms or so before saying yes or no, it doesn't matter what compute power you've got available, a brute force attack is not usually going to be useful, and nor is extra compute power. On the other hand if some idiot has designed it to return quickly, then a brute force attack becomes more practical.

        Have a lot of fun.

        1. Ken Hagan Gold badge

          Re: "...because you have to cycle a 32-bit integer in the kernel around to zero."

          "Suppose you pick a fast syscall and it takes 1us or so, and then the calling programme continues."

          My reading of the article is that only specific syscalls cause the "usage" variable to be bumped, so you can't just pick a cheap one. I don't think the article actually says that explicitly, so I may be wrong, but it seems quite implausible that a 32-bit variable would be touched by every syscall and cause a problem when it wraps. Linux systems stay up longer than that.

      2. JeffyPoooh
        Pint

        Re: "...because you have to cycle a 32-bit integer in the kernel around to zero."

        @Naselus

        The cognitive bias isn't about 'turning the crank', that was a separate point.

        The cognitive bias is (for example) when a company wheels out a spokespuppet that implies that 'difficulty' is equivalent to 'security'.

        Point being, a script can deal with the difficulty, making even very very difficult things extremely easy for zillions of script kiddies.

        e.g. Once upon a time, it was 'very difficult' to hack into satellite TV subscription smartcards. It was 'difficult' in the sense that one left it running while doing something else for 20 minutes. I'm sure it was 'difficult', but the human just clicked and wandered off until it was done. It wasn't actually the slightest bit difficult.

        Point: 'Difficulty' .NE. 'Security'

  9. Steve Graham

    CONFIG_KEYS is set in my Linux kernel build automatically from the dependency logic, which is quite complex, so I haven't yet found out how to unset it.

    It seems to be something in NFS, wifi or bluetooth. The latter two might apply in Android as well.

    1. rjmx
      Boffin

      I just went through that exercise and found the same thing (kernel source 4.4):

      > /usr/src/linux$ find . -name Kconfig | xargs grep "select KEYS"

      > ./fs/cifs/Kconfig: select KEYS

      > ./fs/ext4/Kconfig: select KEYS

      > ./fs/f2fs/Kconfig: select KEYS

      > ./fs/nfs/Kconfig: select KEYS

      > ./init/Kconfig: select KEYS

      > ./net/ceph/Kconfig: select KEYS

      > ./net/rxrpc/Kconfig: select KEYS

      > ./security/integrity/evm/Kconfig: select KEYS

      Looks like selecting any of CIFS, ext4 encryption, f2fs encryption, nfs v4, System Data Verification (whatever that is), Ceph, RxRPC or EVM will select CONFIG_KEYS. Which probably means that, if you build your own kernels, simply turning off CONFIG_KEYS is not an option.

      1. Tim Brown 1

        If you build your own kernel, presumably you'll incorporate the kernel patch for this bug, which has already been released, so you won't have to worry whether CONFIG_KEYS is set or not.

  10. matstegner

    Kernel 4.4.0 was never vulnerable to CVE-2016-0728. Kernels 4.3.4, 4.1.16, 3.14.59 and 3.10.95 all contain fixes for CVE-2016-0728.

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

Biting the hand that feeds IT © 1998–2021