Announcement

Collapse
No announcement yet.

Ubuntu Hit By A Vulnerability In "Eject"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ubuntu Hit By A Vulnerability In "Eject"

    Phoronix: Ubuntu Hit By A Vulnerability In "Eject"

    Ubuntu 12.04/14.04/16.04/16.10 is affected by a new medium priority CVE this morning that could allow a local attacker to execute code as root...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    That's a crazy place for a bug. Good thing its patched now. I think the bigger story is HOW someone found out that the eject function was buggy.

    Comment


    • #3
      I am glad I recently eject out of Ubuntu to Solus.
      But really, at least it was founded and disclosed.

      Comment


      • #4
        Originally posted by dh04000 View Post
        That's a crazy place for a bug. Good thing its patched now. I think the bigger story is HOW someone found out that the eject function was buggy.
        Maybe he did a search on the source tree for all packages in Ubuntu for setuid and setgid functions because he was looking for packages that used those functions in order to investigate if they improperly used them in a way that could be exploited.

        Comment


        • #5
          Good report there: https://bugs.launchpad.net/ubuntu/+s...t/+bug/1673627

          Here's the original report:

          I noticed that dmcrypt-get-device is suid root. it's source code is apparently written at ubuntu (according to the comments)
          The code for which I found at http://archive.ubuntu.com/ubuntu/poo...4-13.1.diff.gz

          which has the following comments:
          Code:
          * Opening /dev/mapper/control requires root privileges, therefore this
          * program needs to be installed setuid root. Root privileges are dropped
          * immediately after querying the information from the device mapper. The
          * parsing is done with normal user privileges afterwards.
          The priv dropping happens in dmcrypt-get-device.c and looks as follows:
          Code:
              /* Drop all privileges */
              setgid(getgid());
              setuid(getuid());
          This unfortunately doesn't account for a failed call to setuid(), which would then perform the parsing as root.
          You'll probably want to fix both the call to setgid() and setuid() with proper return value checks.
          Doesn't look too bad, in my limited understanding. Unless there is a way to deliberately make the setuid and setgid calls fail? Anyone? I would be curious.

          Comment


          • #6
            Originally posted by Sethox View Post
            I am glad I recently eject out of Ubuntu to Solus.
            But really, at least it was founded and disclosed.
            Because a platform that never reports finding bugs is more safe than one that finds and reports them. /s

            Comment


            • #7
              Originally posted by dh04000 View Post
              That's a crazy place for a bug. Good thing its patched now. I think the bigger story is HOW someone found out that the eject function was buggy.
              Agreed. It always amazes me how hackers find the most crazy ways of hacking into something. It takes a lot of creative thinking to figure out this kind of stuff. On the other hand - this is one of the only disadvantages to open-source software: a malicious attacker can spend the time analyzing code for security flaws and get away with performing the attack, at least for a little while. Since apparently security flaws can be found in the most innocent places (such as "eject"), no white-hat hacker is going to go around looking at every binary in the hopes of finding something exploitable. This is even assuming they're creative enough to figure it out in the first place. For black-hats, it's a different story - they tend to have a specific target, so they only need to analyze a narrow scope of potential weaknesses.

              Comment


              • #8
                The real question is why they are using the standalone eject package instead of the one maintained inside util-linux.

                Comment


                • #9
                  Originally posted by hussam View Post
                  The real question is why they are using the standalone eject package instead of the one maintained inside util-linux.
                  The answer is pretty simple: the standalone package predates integration of the utility into util-linux. I believe Debian is now dropping it in favour of the util-linux version.

                  The package in question is not "written at ubuntu" it's imported directly unmodified from Debian. At least, until the patch was added that fixes this bug. The story should actually read "Ubuntu patches a security hole in a Debian package it's redistributing" since anything else is an untruth.

                  Comment


                  • #10
                    Originally posted by bregma View Post
                    The answer is pretty simple: the standalone package predates integration of the utility into util-linux. I believe Debian is now dropping it in favour of the util-linux version.

                    The package in question is not "written at ubuntu" it's imported directly unmodified from Debian. At least, until the patch was added that fixes this bug. The story should actually read "Ubuntu patches a security hole in a Debian package it's redistributing" since anything else is an untruth.
                    The CVE doesn't list Debian as being affected.

                    Comment

                    Working...
                    X