Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Ubuntu Linux

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

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.
This discussion has been archived. No new comments can be posted.

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.

    • by awwshit ( 6214476 ) on Wednesday November 20, 2024 @10:43PM (#64961481)

      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.

      • by Kernel Kurtz ( 182424 ) on Thursday November 21, 2024 @12:50AM (#64961643)
        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.
        • I would think the package manager would be the correct place to do this.

          Sure, why not just make the package manager part of systemd while you're at it?

          RHEL has a needs-restarting app as part of yum utils, but it only looks at core libraries and services.

          Yes, that's another way in which Redhate is inferior to Debian.

          Better an unnecessary reboot than a vulnerability because the admin can't keep track of the patches they are applying.

          You said you wanted the package manager to do it, now you're blaming admins for not doing it manually. Why don't you pick an argument? And while you're at it, learn something about Unix. Having it in a separate program which is called by the package manager is doing it in the package manager.

          • Sure, why not just make the package manager part of systemd while you're at it?

            I have no particular use for SystemD. I'm actually more of a *BSD guy.

            Yes, that's another way in which Redhat is inferior to Debian.

            I've used both RH and Debian based distros over the years. Not much to choose between them IMO.

            You said you wanted the package manager to do it, now you're blaming admins for not doing it manually.

            I said competent admins should be able to keep track manually, but if they can't that is exactly what a package manager is for.

            And while you're at it, learn something about Unix.

            That is why I am more of a BSD guy.

          • Sure, why not just make the package manager part of systemd while you're at it?

            Given how off-topic your rant suddenly became, show us on the doll where systemd touched you.

        • The system package manager doesn't deal with Perl or Python dependencies. I haven't done Perl in ages. Python has it's own pip package manager. Python is cross-platform. If it used the system package manager, there would have to be a per-platform integration. And Windows doesn't even have a package manager. So, instead, Python has it's own package manager. Using the system package manager would let you know if the Python interpreter itself were updated but not if packages managed by Python were updated
          • Sure, I get it. You have a mission critical python program, and 1000 python modules on your server of which the program only uses a handful. Knowing that handful is certainly useful. If you don't, I can see the point of this tool. And maybe you have mission critical Python, Perl, and Ruby programs all on the same server and don't know any of their dependencies either, at which point I would suggest avoiding unnecessary restarts is the least of your problems.
            • If you have a mission critical Python program plus a thousand unnecessary modules, you're already in trouble. I don't do much systems administration these days but I believe that mission critical applications normally get their own runtime environment whether that be an entire VM, a Docker Container, or an isolated K8s ReplicaSet. It seems that the needrestart app is targeted more toward small/medium businesses who use a handful of Linux servers for their internal tasks and restarts of the whole box are
              • I'll admit the 1000 modules comment was a bit tongue in cheek, but if you can't tolerate restarts that to me seems to fit the definition of mission critical (or just very poorly designed).

                I guess someone has to rep for all the part time sysadmins of mission critical and/or poorly designed applications though. Seems apropos in that regard.
    • 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 >
        • Re: (Score:2, Troll)

          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.

          • That's it. I don't even connect that music box to the internet except to get software from time to time. So, as a segregated machine, where I know it's not going to used for any sensitive topics, it's fine.

            For my use and clients with a clue, I use virtual machines for "office work", business work, which I find quite useful to keep sensitive data separate from the base system. I can maintain and roll out improvements to multiple boxes as a software update, instead of having to sit infront of their screens. I
        • The man pages for systemd are still needlessly confusing but it is itself a better init now than sysv.

          246, I think, fixed the last of the bozo problems.

          I miss O'Reilly books.

          • I'll have to push back on that, but we don't need to descend into name calling.
            There's nothing sysd does that you couldn't have written as script for, if you have the technical know how.
            A script that would be a tiny fraction of the size, that does exactly what YOU want, and that you can fix or modify whenever you want.
            A script where you are in control.

            I figured that out when I got into running my own name servers then found it virtually impossible to configure name resolution with sysd standing in the way.
      • by gweihir ( 88907 ) on Wednesday November 20, 2024 @10:13PM (#64961421)

        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.

        • Devuan is the cleaner solution though.

          Nothing says "cleaner" and "KISS" more than writing a separate startup script for every application and then having your init system start a second init system to handle on demand services and monitor daemons it was unable to do itself. /s

    • 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 vbdasc ( 146051 )

        The woes of using Debian testing...

        As of now, the vulnerability is patched on Debian oldoldstable, oldstable, stable and unstable, but not on testing. It will need several days for the patch from unstable to reach testing. Whoever is using Debian testing for production (like me) better upgrade needrestart from sid. Or make sure that bad guys don't get local access :)

        • Sometimes using kernel and packages from backports works out better for production than testing.

        • by tsm_sf ( 545316 )

          Or make sure that bad guys don't get local access :)

          Are we no longer assuming local access means you've already been rooted?

  • 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

    • The following additional step could be handy:

      ~# mount / -rw -o remount

    • You will end up in a root shell

      Not on my system you won't, but then I use ZFS with FDE.

      P.S. You can get this with the installer on Ubuntu, or I think on the latest Debian. On Devuan I had to do it manually, but it was pretty easy even with the differences from the Debian instructions (if you understand at all what you're doing, it's easy enough to figure out how to make the changes.)

    • I think that local access != console access. Looks like anyone with a user account and a shell can get root, if they're content to create some files or run some processes and then wait for a system update.

    • They didn't mean local access as in physical access. They meant access to a non-privileged account. Admittedly TFS was very sloppy.
    • That wont work if they have a grub password set.
  • 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

  • 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

      • I still get that message on my Zen4 desktop PC. Try booting your computer without a keyboard.

    • 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

      • Sun was the best of Unix's in the day.

        Yeah, in version 4.x.

        I kid, I kid. Solaris was pretty good through about 2.5.

      • Sun had the best error messages, though.

        Shout out to the documentation team if you're still out there.

        Linux interrupts are still stupid too. I only just the other day found udev rules to make USB writes 50x faster on slower media, which is not the default.

        Every five years lkml decides to do something about it but then suddenly loses interest.

        I also learned that now cat foo > bar is ten times faster than dd if=foo of=bar no matter the block size because of some lame syscall inefficiency.

        At least Sun neve

    • 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.

        • 50% of cross-platform code is #ifdefs.

          If you're doing it like this, you're doing it wrong. Encapsulate the incompatibilities into individual functions, and shove them into a file/class/directory and be done with it. Don't let the #ifdefs pollute the entire codebase.

          Also, with a lot of compilers the #ifdefs can be used in if statements, like:

          #define OPENSYS 1
          if(OPENSYS) {
          do_opensys_stuff();
          }

          The stuff inside the if statement will be ignored if OPENSYS is false. Functionally equivalent, but maybe more readable.

          • If you're doing it like this, you're doing it wrong. Encapsulate the incompatibilities into individual functions, and shove them into a file/class/directory and be done with it. Don't let the #ifdefs pollute the entire codebase.

            From a design perspective, of course this is how one does it.
            However, codebases evolve over time. See the linux kernel for examples of how the most used piece of software on the planet is doing it wrong.

            Also, with a lot of compilers the #ifdefs can be used in if statements, like:

            Absolutely.
            That's simply not how it's done in many cases however. Blame history, tradition, and autoconf for that.
            If you're trying to specify a #define on the command line of your make, you can't have it statically set within your code.

            Further, #ifdef is more efficient for the computer to exclude code f

  • 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

      • No need for sudo with apt unless you actually going to make changes to the system - installing or removing packages: no root needed for read-only stuff like 'apt show need-restart".
        Heck, I don't think I have sudo on my personal machines even.

        • Ahh that makes sense. I wasn't sure and tend to use sudo any time I'm invoking apt, though I suppose the vast majority of the time I'm install, updating or removing an application, so I would need to.

    • >"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 cstacy ( 534252 )

        >"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 there is a package called "Needrestart", click on it.
        4) Notice it will say "INSTALL" if it is not installed or "Remove" if it is installed. Either way, it will show the version under the Details tab.

        So exactly how would that be easier on some other platform. Waiting....

        I've been waiting for decades, myself.
        You and the previous commenter make my case.

        The vulnerability reporting (screaming in the headlines) would never mention the system component that needs updating or it's version, and the user would never type any commands.

        Instead, the headlines would read something like, "Apple Zero-Day..." and the entire instructions would be "Make sure your system is up to date and you will be fine." Like on my phones and laptops this morning. And if you are a more technical user or a

        • >"The vulnerability reporting (screaming in the headlines) would never mention the system component that needs updating or it's version, and the user would never type any commands."

          Right. So, Mint will have an update alert, you just apply the updates and you are done.

          >"The idea of a desktop that your Grandmother can use is that they don't need to know anything technical at all."

          Then turn on the option for automatic updates and you are done.

          >"And in case it's not clear: Someone else in the thread j

          • by cstacy ( 534252 )

            >"The vulnerability reporting (screaming in the headlines) would never mention the system component that needs updating or it's version, and the user would never type any commands."

            Right. So, Mint will have an update alert, you just apply the updates and you are done.

            Which of course I had already done.
            (Well, actually, I click the updater button on the dock
            manually, in case I hear "Uh Oh! Don't run that update
            everyone said you need. They botched the patch and
            it might brick your system!".)

            But the cultural difference is that with Linux,
            the headline is about the specific version of
            an internal component. And more importantly
            no instructions on how to know if you are
            successfully updated. By contrast, the headline
            with say Apple (this happened in the last two days)
            just says "the

    • 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

      • by cstacy ( 534252 )

        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]

        My grandson said I have "Mint" which is Linux.
        And that Linux is better than Windows or a Mac.
        What is an Ubuntu? Is that something I need to download?

        I am a good Googler, especially now that it has AI.
        Should I look for "fix your Ubuntu" and click on whatever
        that leads to and say "YES" when it asks for root?
        But the last time I did that, I had problems for days
        until I called my grandson to ask him what Bitcoin was.

    • 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.

    • Try:

      dpkg -l needrestart

      dpkg is the package manager that all Debian-derived distros use.

      that's a dash lower case L not upper case i or pipe (if your typeface is as bad as mine).

      dash L is "list" versions.

      If the first column says 'ii' it's installed. Then look at the version label.

      • by cstacy ( 534252 )

        Try:

        dpkg -l needrestart

        dpkg is the package manager that all Debian-derived distros use.

        that's a dash lower case L not upper case i or pipe (if your typeface is as bad as mine).

        dash L is "list" versions.

        If the first column says 'ii' it's installed. Then look at the version label.

        "No packages found matching needrestart".
        So.I guess I am good to go!
        (I tried the command on some things I know are installed,
        to make sure it was working.)

        Thank You!

        Your suggestion was much simpler than most of
        the various things that most other posters advised.
        Most of them also included very nasty insults,
        and even said that I abandon Linux.
        I wonder what that means.

        This isn't as easy as on a consumer grade system,
        where I would never need to even know that this
        component existed. But for a package-oriented
        multi

    • This is all weird to me, I have no vanilla Debian systems but on Devuan I have debian-goodies installed and it provides checkrestart, which needrestart was "inspired by". So I am running a Debian variant, I have the same functionality, but I do not have the vulnerable package installed.

      • by cstacy ( 534252 )

        This is all weird to me, I have no vanilla Debian systems but on Devuan I have debian-goodies installed and it provides checkrestart, which needrestart was "inspired by". So I am running a Debian variant, I have the same functionality, but I do not have the vulnerable package installed.

        Hopefully someone is auditing "checkrestart" now, too.

        • I had the same thought for sure. I'm sure lots of people are, I hope some of them are supposed to be ;)

  • Oh, wait, this is Linux? Well then, the vulnerability is OK because it was addressed.
    • Privilege escalation exploits are a dime a dozen on both Linux and Windows, and even OpenBSD doesn't guarantee against them. The attack surface is large, and designed without security as the priority.
  • rm /needsrestart
    # Do some package installing
    if restart_needed; then touch /needsrestart;fi

    Afterward you don't need any root binaries to determine if a restart is required. It's not like it would change all the time. If you ran apt, you may need a restart afterward, but that won't go away ... until next restart. So why should there be a program that does more than "test -e /needsrestart && echo 'Restart needed'"?

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (3) Ha, ha, I can't believe they're actually going to adopt this sucker.

Working...