Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Ubuntu Linux

Ubuntu Linux Impacted By Decade-Old 'needrestart' Flaw That Gives Root (bleepingcomputer.com) 41

Five local privilege escalation (LPE) vulnerabilities in the Linux utility "needrestart" -- widely used on Ubuntu to manage service updates -- allow attackers with local access to escalate privileges to root. The flaws were discovered by Qualys in needrestart version 0.8, and fixed in version 3.8. BleepingComputer reports: Complete information about the flaws was made available in a separate text file, but a summary can be found below:

- CVE-2024-48990: Needrestart executes the Python interpreter with a PYTHONPATH environment variable extracted from running processes. If a local attacker controls this variable, they can execute arbitrary code as root during Python initialization by planting a malicious shared library.
- CVE-2024-48992: The Ruby interpreter used by needrestart is vulnerable when processing an attacker-controlled RUBYLIB environment variable. This allows local attackers to execute arbitrary Ruby code as root by injecting malicious libraries into the process.
- CVE-2024-48991: A race condition in needrestart allows a local attacker to replace the Python interpreter binary being validated with a malicious executable. By timing the replacement carefully, they can trick needrestart into running their code as root.
- CVE-2024-10224: Perl's ScanDeps module, used by needrestart, improperly handles filenames provided by the attacker. An attacker can craft filenames resembling shell commands (e.g., command|) to execute arbitrary commands as root when the file is opened.
- CVE-2024-11003: Needrestart's reliance on Perl's ScanDeps module exposes it to vulnerabilities in ScanDeps itself, where insecure use of eval() functions can lead to arbitrary code execution when processing attacker-controlled input.
The report notes that attackers would need to have local access to the operation system through malware or a compromised account in order to exploit these flaws. "Apart from upgrading to version 3.8 or later, which includes patches for all the identified vulnerabilities, it is recommended to modify the needrestart.conf file to disable the interpreter scanning feature, which prevents the vulnerabilities from being exploited," adds BleepingComputer.

Ubuntu Linux Impacted By Decade-Old 'needrestart' Flaw That Gives Root

Comments Filter:
  • by Kernel Kurtz ( 182424 ) on Wednesday November 20, 2024 @08:05PM (#64961243)
    It uses Python, Perl, and Ruby? Nothing like maximizing your attack surface.
    • by gweihir ( 88907 )

      Yep. Sounds like somebody at Ubuntu _really_ does not understand KISS or IT Security. Pathetic.

    • PHP FTW?

    • by pavon ( 30274 ) on Thursday November 21, 2024 @12:04AM (#64961585)

      The purpose of needrestart is to check if any running software is using packages that have since had new versions installed, so you can restart just the software that needs to be restarted rather than rebooting the whole machine. So of course it uses python to check python software, and perl to check perl software, etc. Nothing wrong with that. Using OS package manager dependencies would result in tons of false positives, and doing everything in a single language would result in a ton of reinventing the wheel and thus likely introduce more security bugs rather than use the functionality that the various language ecosystems already provide.

      • I would think the package manager would be the correct place to do this. RHEL has a needs-restarting app as part of yum utils, but it only looks at core libraries and services. In any case I'd be more concerned about false negatives than false positives. Better an unnecessary reboot than a vulnerability because the admin can't keep track of the patches they are applying.
    • Sometimes I wonder if something that is security critical should be done in a language designed for security. Rust might be the best compromise, but maybe even Ada, although even the DoD seems to have abandoned that.

  • by williamyf ( 227051 ) on Wednesday November 20, 2024 @08:17PM (#64961257)

    As it seems that there are not enough eyes looking at Ubunto to make the bugs shallow.

    Maybe those eyes got distracted? MIR&Unity? Ubuntu Phone? Snap?

    • Switching to Debian instead of going all the way and switching to Devuan to actually get rid of the crappiest software is half-assing it.

      • Damn Right.

        Currently I'm testing Ceres and it work like a charm.

      • It's a trap, Luke! (Score:5, Interesting)

        by Big Hairy Gorilla ( 9839972 ) on Wednesday November 20, 2024 @09:49PM (#64961397)
        I think your use case has something to do with it. I use Devuan on most of my bread and butter servers, web, email, name servers, jabber, pffft. I have a vpn hub running only 96 processes in total. It's super solid and is a low low maintenance load on me. Can't argue with that. It's what Debian is supposed to be.

        But, unfortunately, I had to wimp out and use Debian on a midi music box. I find there's just too many moving parts in midi and digital audio recording system that most likely have dependencies on the dreaded ... thing whose name shall not be spoken... <whispers: systemd> ... I followed Ted Felix's instructions intended for Ubuntu, onto Debian, and honestly it was still a pain in the ass to get right. I wanted to remove the system as a possible source of errors... So in other words, I'm lazy, but with that long excuse.

        For the most part though, it hasn't been a terrible experience. It boots fast and recognizes all the midi and audio hardware. I think that Debian has finally made installation of wifi drivers just part of the normal installation, so good on them for finally smoothing that over. The system is pretty well behaved now. Debian has been fit for the task. Even I can admit that. <stares at shoes a bit then shows self out >
        • by gweihir ( 88907 )

          Well, most of Debian is still good. They just did not understand enough what the manipulators were doing and hence allowed systemd in, despite massive misgivings. Fortunately, Devuan fixes that in most scenarios. And I will not even say that running Debian for a low-reliability, low-security box is a bad thing as long as you are aware that it is essentially a sabotaged system.

      • by gweihir ( 88907 )

        Indeed. Systemd is even more a KISS violation than this thing here. Although Debian still works without systemd. Devuan is the cleaner solution though.

        • I tried Debian with sysvinit and I kept running into problems. I wanted it to be OK, but it wasn't. It was just too much time spent fixing thing after thing where it was already fixed on Devuan. I used the Debian instructions for root on ZFS (from the linux ZFS page) with some minor tinkering (easy for anyone with the basics really) and I have been running happily for two versions now, including a completely successful upgrade to daedalus.

          The only places I've really run into friction were that my machine ke

          • by gweihir ( 88907 )

            Interesting. I have two machines left (one server and one desktop) on Debian/sysvinit, with no problems. They are mostly very vanilla installations, but with some of my own init-scripts and running my own kernels. I always liked that you can run Debian easily with your own no-modules no-initrd only-needed-drivers kernel. That closes a whole lot of security headaches right there.

            I will eventually migrate these to Devuan on the next dist-upgrade though.

    • need-restart had a security-update the other day on my Debian boxes, and apt autoremove ditched a lib in the process. Now I see why.

      And yes, I've been using needrestart for years. It keeps track of upgraded dependencies so much better, then suggests in an ncurses window a selection of services to restart. I still get to decide what action to take - restart a service, X, or the whole box. Sometimes I choose to postpone, schedule for overnight.

      I like.

  • by willkane ( 6824186 ) on Wednesday November 20, 2024 @09:02PM (#64961341)

    The report notes that attackers would need to have local access...

    In that case:

    - reboot

    - on grub menu, edit the boot entry (pressing 'e')

    - append to the linux boot line the following: init=/bin/bash

    - press F10 to boot

    You will end up in a root shell

  • I'm on Debian, but the vulnerable package was installed here too. I took a look at the source code and config files of needrestart and determined that the best course of action was this:

    apt purge needrestart

    • >"I'm on Debian, but the vulnerable package was installed here too."

      I just checked my home Mint 21.3 system and needrestart is not installed. It is an available package (3.5-5), but apparently is not installed by default nor was pulled in by any of the many things I have installed.

    • by gweihir ( 88907 )

      Interesting. Any idea how it got in there?

    • Rebooting is for Windows users :)

  • by Valgrus Thunderaxe ( 8769977 ) on Wednesday November 20, 2024 @09:16PM (#64961359)
    But I'm old enough to remember this same nonsense and controversy when Solaris transitioned to SMF.
    • Keyboard not found. Press F1 to continue.

      Hah, your sig made me laugh. Would seriously not be surprised if it's based on reality.
      Made me think of the error I got from Tcsh **way** back, "Assertion botch: This can't happen!" (so... helpful) :-)

      • Hah, your sig made me laugh. Would seriously not be surprised if it's based on reality.

        Real message from Phoenix BIOS circa 1997-2000.
      • by Scoth ( 879800 )

        That was a standard error message on IBM PC compatible BIOSes from pretty much the beginning through to more or less today.

        The idea being that booting a computer without a keyboard was generally considered useless, so if it didn't detect one it made you plug it in and prove you had one.

        Not sure why so many people don't understand why the error actually makes sense. You could also disable it in most BIOSes by at least the 486 era, and probably even some 386 ones, on the chance you had a machine you didn't ne

    • by upuv ( 1201447 )

      OMG SMF was/is a disaster.

      Or the time when they moved networking out of the kernel. Now that was a mess.

      Or when Sun switched to CDE as the GUI.

      Or Cluster patching in general an administrative nightmare.

      Sun was the best of Unix's in the day. HPUX being right up there as well. All the issues I mention with Solaris were 10x worse on HPUX. When Oracle bought Sun they did the industry a service. As it accelerated the adoption of linux. An OS where things actually get patched. And the patches can actually

    • Did SMF ever interfere with dns queries? Did it cause software to be non portable because of SMF dependencies?

      • Did SMF ever interfere with dns queries?

        If you don't like how systemd-resolve does things.... don't use it?

        Did it cause software to be non portable because of SMF dependencies?

        Couldn't help but laugh at this. You don't write software for unices, methinks.
        Fucking nothing is portable, past int main(int argc, char **argv) { printf("Hello world!\n"); }
        50% of cross-platform code is #ifdefs.

  • I have Mint 22 LTS Wilma, and looking that up in Google tells me that it's based on Ubuntu 22. The summary here says the problem is fixed in needrestart version 3.8. Armed with all this information, I still have no clue as to whether I am safe. (Trying needrestart --version doesn't lead anywhere, since it's not an executable anywhere on my path.)

    How is a user supposed to know if they are safe?
    If this were Windows or MacOS, the answer would be straightforward and simple. Because those systems are for ordinar

    • Or you could just do a simple duck duck go search. Here, type this if you are on an apt based system.

      sudo apt list --installed | grep "need"

      This will return all packages with "need" in the name. You could also just drop the " | grep "need" " and just do sudo apt list --installed

      This will list out all the applications installed. You can just scroll through and find what you want.

      It's okay if you aren't nerd enough for Linux. We really don't want it to go mass end user anyway. Everything that goes mass user e

    • >"I have Mint 22 [...]If this were Windows or MacOS, the answer would be straightforward and simple. Because those systems are for ordinary users out of the box. Another example of Linux desktop not being ready for prime time, apparently understanding what a normal desktop user[...]"

      Right, such a great example. Let's see just how difficult it is for an "ordinary user" in Mint.

      1) Launch "Software Manager" (hint: LM button > Admin > )
      2) Type "needrestart" in the search box and press enter.
      3) Notice

    • by gweihir ( 88907 )

      The simple approach is to check Mint security alerts, i.e. the analog of https://www.debian.org/securit... [debian.org]
      Although it seems that Mint does not have such a feature? That would not be good.
      Ok, then use the Ubuntu one: https://ubuntu.com/security/no... [ubuntu.com]

      As to checking, I assume that Mint keeps Ubuntu package versions. Then the standard
      dpkg -s | grep '^Version:'
      should give you more. As will, incidentally, whatever package management tool you prefer.

      This is really not too much to ask, IMO. M

    • open a terminal and do: f.ultra@Sineya:~$ apt-cache policy needrestart
      needrestart:
      Installed: (none)
      Candidate: 3.6-7ubuntu4.3
      Versionsl:
      3.6-7ubuntu4.3 500
      500 http://se.archive.ubuntu.com/u... [ubuntu.com] noble-updates/main amd64 Packages
      500 http://se.archive.ubuntu.com/u... [ubuntu.com] noble-updates/main i386 Packages
      500 http://security.ubuntu.com/ubu... [ubuntu.com] noble-security/main amd64 Packages
      500 http://security.ubuntu.com/ubu... [ubuntu.com] noble-security/main i386 Packages
      3.6-7ubuntu4 5

      • My bad, 3.6-7ubuntu4.3 was in fact the version that had the fix backported. The backported version for 20.04 is 3.6-7ubuntu4.3
    • by vbdasc ( 146051 )

      (Trying needrestart --version doesn't lead anywhere, since it's not an executable anywhere on my path.)

      Try executing needrestart as a root, because it's a superuser command. If it's not found, then it's not present in your system and you're safe.

"I got everybody to pay up front...then I blew up their planet." "Now why didn't I think of that?" -- Post Bros. Comics

Working...