Announcement

Collapse
No announcement yet.

Ubuntu Hit By A Vulnerability In "Eject"

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

  • #11

    Originally posted by Util-linux 2.22 Release Notes {Sep 4, 2012}
    eject(1): - has been merged from inactive upstream from sf.net and Fedora into util-linux - supports new options --manualeject, --force and --no-partitions-unmount
    Does that mean debian and ubuntu have been removing eject support from util-linux for 4+ years now ?

    Comment


    • #12
      Originally posted by bregma View Post
      The answer is pretty simple: the standalone package predates integration of the utility into util-linux.
      That's atleast part of the answer.

      Originally posted by bregma View Post
      I believe Debian is now dropping it in favour of the util-linux version.
      Not until someone does the actual work. Patches welcome.
      (This involves both the old eject package, the util-linux packages and the debian-installer because of eject-udeb which maybe should just be replaced by applets from busybox.)

      Originally posted by bregma View Post
      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.
      Not quite true. The vulnerability was in the "dmcrypt-get-device" utility. That tool has been bundled into the eject package but doesn't come in the upstream sources for the package. It's true that this happened in the Debian package (which was imported to ubuntu), but where did this tool come from? Read the sources and you'll find out.... (spoiler alert: Canonical).

      Greetings from your Debian util-linux maintainer. Looking forward to reviewing your patches to deprecate the eject source/package!

      Comment


      • #13
        Originally posted by LoneVVolf View Post
        Does that mean debian and ubuntu have been removing eject support from util-linux for 4+ years now ?
        Debian never ever shipped eject from util-linux, so it was never "removed".

        If you prefer the util-linux implementation (which is just one of very many eject implementations being used in the wild) then feel free to post patches for transitioning over to that one in Debian.

        Comment


        • #14
          Originally posted by monraaf View Post

          Debian never ever shipped eject from util-linux, so it was never "removed".
          To clarify, we never shipped a binary built from util-linux source of eject. The source has always shipped in the util-linux source package since util-linux grew an implementation of eject.

          Comment


          • #15
            Originally posted by TheBlackCat View Post
            The CVE doesn't list Debian as being affected.
            Just don't read that Ubuntu only shit, but common one

            https://cve.mitre.org/cgi-bin/cvenam...=CVE-2017-6964

            It is patched in Debian also:

            https://lists.debian.org/debian-secu.../msg00079.html

            Comment


            • #16
              Originally posted by monraaf View Post
              Debian never ever shipped eject from util-linux, so it was never "removed".
              Eject is enabled by default in util-linux and manually disabled in Debian, so I don't think it is inaccurate to say it is "removed".

              Comment


              • #17
                Originally posted by [email protected] View Post
                Good report there: https://bugs.launchpad.net/ubuntu/+s...t/+bug/1673627


                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.
                From a similar bug report for GlusterFS (http://lists.gluster.org/pipermail/b...st/032052.html)

                "Note: there are cases where setuid() can fail even when the caller is UID 0; it is a grave security error to omit checking for a failure return from setuid(). if an environment limits the number of processes a user can have, setuid() might fail if the target uid already is at the limit."


                Comment


                • #18
                  Originally posted by dh04000 View Post

                  Because a platform that never reports finding bugs is more safe than one that finds and reports them. /s
                  I agree that moving from Ubuntu to Solus doesn't really make things safer per se, but Solus does report finding bugs. I frequently see that in the Updates tab in the Software Center (click the Information icon) or on git.solus-project.com.

                  Comment


                  • #19
                    Originally posted by schmidtbag View Post
                    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.
                    this is also the best guarantee: if no one found a bug, the software can be considered secure, after some time depending on the complexity of the code

                    this is why stable and development branches are separate, to let stable versions to maturate their guarantee

                    with closed source you can never be sure

                    Comment


                    • #20
                      Originally posted by bellamyb View Post

                      From a similar bug report for GlusterFS (http://lists.gluster.org/pipermail/b...st/032052.html)

                      "Note: there are cases where setuid() can fail even when the caller is UID 0; it is a grave security error to omit checking for a failure return from setuid(). if an environment limits the number of processes a user can have, setuid() might fail if the target uid already is at the limit."

                      Uhm, so, what, first fork-bomb your own account, then trick a binary not checking setuid success into doing setuid to it?

                      Comment

                      Working...
                      X