Sign in / up

back to article Ubuntu to shutter year-old clock unlock bug

Ubuntu's latest edition contains a local access escalation flaw first reported a year ago that allows users to tinker with the system clock to become a root user. The attack, reported by Linux lover Mark Smith, isn't colossally risky as it impacts only local users; those with existing access to a machine. Smith has chided …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. Anonymous Coward
    Anonymous Coward

    Shortsighted reaction on the side of Canonical

    You can only change the clock using this bug you say? This wouldn't be so bad in itself weren't it for the following:

    - SSL depends on a correct date and time setting to verify certificates

    - different tools create hidden files in the users home folder indicating previous successful root authentications

    The second problem can be used to very nicely exploit. Change the system clock to *right* after one of those files was created and it will think that you very recently authenticated as root and thus don't have to enter your password again. This can be used to gain full root access.

    6 1 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Shortsighted reaction on the side of Canonical

      Yes - the consequences of changing the system clock are pretty unpredictable. It is at least going to have an effect on any piece of code that looks at the time and can't handle time going backwards sensibly. How many coders worry about that?

      A bit like when buffer overflows emerged as a serious problem - without doing an extensive audit who knows where this might causes vulnerabilities and what they are.

      0 1 Reply
    2. Sotorro
      Reply Icon
      FAIL

      Re: Shortsighted reaction on the side of Canonical

      The article states "Ubuntu's latest edition", which would suggest it's only the new version 15, but all versions seem to be affected, from 12 onwards. see: http://osdir.com/ml/ubuntu-bugs/2015-04/msg21177.html

      Versions affected are:

      Ubuntu 12.04.5 LTS (Precise Pangolin)

      Ubuntu 14.04.2 LTS (Trusty Tahr)

      Ubuntu 14.10 (Utopic Unicorn)

      Ubuntu 15.04 (Vivid Vervet)

      As Martijn Otto already stated, this bug can give, already locally logged on users sudo rights potentially.

      0 1 Reply
    3. Sotorro
      Reply Icon
      Go

      Re: Shortsighted reaction on the side of Canonical

      I have found out why this is not considered a bug by Ubuntu but a feature.

      You need to have used sudo as an Admin first before it gets an issue, normal users can normally not set the clock and need sudo first to set it. So you can not really elevate privilege with it under normal conditions, as you normally are not logged in as an Admin.

      But when you are logged on with an Administrative account it can indeed become a problem, the idea though is that when remote users can log in to your box as an Admin you have probably worse problems on your hand, then just this issue, and there for they consider it more of a physical access problem at best.

      Some people have how ever argued that this is still somewhat of a bug and that even though it's not remotely exploitable, it would be nice if you needed to authenticate again to set the time, even as an Admin.

      A possible work around if you feel that this should not be possible, is to set the grace time of sudo to zero.

      In other words set, Defaults timestamp_timeout=0 ,in the Defaults section of your /etc/sudoers

      1 0 Reply
      1. Doctor Syntax Silver badge
        Reply Icon

        Re: Shortsighted reaction on the side of Canonical

        "normal users can normally not set the clock and need sudo first to set it"

        The actual bug report (follow the mailing list link in the article) starts off with the statement that "Under unity and cinnamon, it is possible for a user to turn off network-syncronized time and then change the time on the system." The implication is that this is possible for an unprivileged user. If so then this certainly is a bug. Not only does it enable the privilege escalation that the bug report goes on to describer, it makes one wonder if the code underlying this enables other functions that should be impossible for an unprivileged user.

        I can't say I was ever happy with the Ubuntu version of sudo. It uses the user's own password to gain superuser access providing the user is in the sudoers list. An unprivileged user who learns such a password instantly gets admin access. It's always seemed preferable to me that a second password, that of root, should be needed.

        1 1 Reply
        1. brotherelf
          Reply Icon

          Re: Shortsighted reaction on the side of Canonical

          I've never seen a distro that configured it the other way around by default – the entire point of sudo (over su) is that you don't need the root password to execute a limited, admin-granted selection of commands with elevated privileges. Of course, usually, one doesn't put a shell in there.

          1 0 Reply
          1. Doctor Syntax Silver badge
            Reply Icon

            Re: Shortsighted reaction on the side of Canonical

            "a limited, admin-granted selection of commands with elevated privileges"

            It depends on the circumstances.

            If you're thinking of a large installation with a large admin team sliced up so each user can only do limited tasks then that provides a use case for the Ubuntu arrangement.

            But Ubuntu is a popular desk-top system. If someone discovers that fred's ordinary password is fl1nst0ne then any time they come across his desk-top unattended they can install their favourite key-logger or whatever. In such a system a 2 factor authentication scheme would be better. Having a single password for logon & sudo is just a single factor used twice. And that's not 2 factor.

            "I've never seen a distro that configured it the other way around by default"

            That's how I'm using Debian 7 right now.

            0 1 Reply
        2. thames
          Reply Icon

          Re: Shortsighted reaction on the side of Canonical

          The discussion evolved quite a bit from his original description, which was rather vague and impractical. The person who reported it was working on finding a way to brute force an exploit, but at the time of writing this comment he still hadn't.

          As for the original method, the Canonical guy said "If you have administrative users that are leaving session unlocked, you have a more serious security issue than being able to change the time." To make a long story short, if you have administrator access you can do administrative things. The Canonical guy isn't blowing the issue off, he's just saying 'show me a feasible exploit that doesn't require initial conditions that are not a serious security problem on their own'.

          I'm not going to criticize the guy who reported this as a bug. I would rather have an overly paranoid set-up than an overly lax one. Even if he can't make a practical exploit out of it, someone else may find a way to do so later.

          I won't be surprised if Ubuntu closes this by updating to the latest version of "sudo", but I have to agree that it's not a serious issue at this time. If you are worried about it, just use "-k" with sudo or close your admin terminals before leaving your computer logged in, unlocked, and unattended.

          1 0 Reply
  2. damian fell

    Insider risk not appreicated by interviewee

    Sometimes we can as professionals be blind to the breadth of threats to information assets.

    The interviewee here is thinking in the mindset that the only threats worth defending against are those of remote actors, when in most organizations there are internal threat actors that are just as important, and the constraint of admin access to corporate devices is an important part of protecting against that.

    If you "cant see a way" that this is a threat, Imagine a disgruntled employee with physical access, using this to elevate privileges and install a key logger to capture credentials for other systems.

    3 2 Reply
    1. Gordon 10
      Reply Icon
      FAIL

      Re: Insider risk not appreicated by interviewee

      Have to call you out on that one. He didn't say it wasn't a threat he said it was lower risk than most. The worst thing you can do in security is trying to remediate all risks rather than accepting the lower ones after a suitable risk assessment.

      Its all about the size of the attack surface. Any computer in physical possession of a technically competent member of staff with a grudge is vulnerable. Factor in the fact that the volume of corporate deployments of unbuntu as a desktop are pretty few and far between - I agree with Canonical - there are bigger things to use scarce resources on.

      2 4 Reply
    2. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Insider risk not appreicated by interviewee

      Especially since a remote attacker can find other ways to get his code run as an unprivileged user on a target machine, and then all he needs is exactly a privilege escalation vuln. Many attacks are carefully built using several holes at once, moving sideway, etc. not just looking for a single, high risk one on the target machine.

      0 0 Reply
  3. Crazy Operations Guy

    "I don't see a way for an attacker,..."

    Just because you don;t see it, doesn't mean that there isn't something waiting to bite you in the ass... Blase attitudes towards security are why I abandoned Linux some time ago in favor of BSD.

    0 0 Reply

POST COMMENT House rules

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

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like