Surprised nobody mentioned this yet, or I'm just too dumb to use the search function... 

 

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3156

 

This is huge, a hotfix would be nice.

Does not seem too relevant to Unraid as the admin user is already running as root so there is never any need to use sudo.   Unraid does not have users in the traditional Linux meaning

Under the hood, Unraid is using the concept of different users with different privileges in the traditional *nix sense, just like any other distro. Just because you get a root prompt when you click the console icon does not mean its not relevant. The issue here is not someone with console access having root privileges, its more about potential privilege escalation in all the services and processes that are not running as root! This is a major crack in the standard *nix security concept.

5 hours ago, sir_storealot said:

This is huge, a hotfix would be nice.

A workaround for this would be to do it on your own for now until a fix is released, since Unraid is based on Slackware this is pretty straight forward...

 

Open up a Unraid terminal and enter the following:

 

cd /tmp
wget http://slackware.cs.utah.edu/pub/slackware/slackware64-14.2/patches/packages/sudo-1.9.5p2-x86_64-1_slack14.2.txz
installpkg sudo-1.9.5p2-x86_64-1_slack14.2.txz
rm -rf /tmp/sudo-1.9.5p2-x86_64-1_slack14.2.txz

 

You can also append this to your 'go' file to install it on every reboot.

 

I know this is only a temporary solution but it's a solution that works.

After that you can issue 'sudo -V' in the terminal and you will see that you now have sudo 1.9.5p2 installed.

 

(Btw the package is from the official Slackware repo)

 

 

 

EDIT: Wrote a quick Plugin if this is what you are after, it will do basically the same and you don't have to edit anything (works only from Unraid version 6.8.2 to 6.9.0rc2):

https://raw.githubusercontent.com/ich777/unraid-sudo-patch/master/CVE-2021-3156.plg

 

3 hours ago, sir_storealot said:

Under the hood, Unraid is using the concept of different users with different privileges in the traditional *nix sense, just like any other distro. 

Is it though? I thought that under the hood there werent any other real (in the sense of *nix) users defined. 

3 hours ago, sir_storealot said:

The issue here is not someone with console access having root privileges, its more about potential privilege escalation in all the services and processes that are not running as root!

How would that look on unraid, exactly? Can you walk us through a sample attack that would use a privilege escalation on a typical unraid setup?

18 hours ago, ich777 said:

 

EDIT: Wrote a quick Plugin if this is what you are after, it will do basically the same and you don't have to edit anything (works only from Unraid version 6.8.2 to 6.9.0rc2):

https://raw.githubusercontent.com/ich777/unraid-sudo-patch/master/CVE-2021-3156.plg

 

 

Thank you for your help, this is awesome! 👍

15 hours ago, primeval_god said:

Is it though? I thought that under the hood there werent any other real (in the sense of *nix) users defined. 

 

Go to the console and do "ps waux", you will see that many services run as non-root users. The reason for this is to limit the damage that an attacker could do if a service gets compromised.

 

15 hours ago, jonathanm said:

How would that look on unraid, exactly? Can you walk us through a sample attack that would use a privilege escalation on a typical unraid setup?

 

That would really depend on what services you are running, but basically any vulnerability in a daemon, service, script etc. that is accessible via the net, processes information that might be malicious etc. could result in root access.

 

Just to be clear, it does not mean that unraid servers are now all vulnerable or can be easily hacked/compromised. Nono... An attacker would still need other means to gain local non-root access, but unfortunately that is not uncommon. How big the risk is depends on your system, only you can judge.

 

Look up the "swiss cheese model", this is now basically another hole in the cheese, on its own it wont do anything, but if it lines up with other holes it may lead to an incident, so thats why I like to see this hole stuffed

 

Hope this helps, cheers guys and take care!

On 1/28/2021 at 8:52 PM, ich777 said:

A workaround for this would be to do it on your own for now until a fix is released, since Unraid is based on Slackware this is pretty straight forward...

 

Open up a Unraid terminal and enter the following:

 

cd /tmp
wget http://slackware.cs.utah.edu/pub/slackware/slackware64-14.2/patches/packages/sudo-1.9.5p2-x86_64-1_slack14.2.txz
installpkg sudo-1.9.5p2-x86_64-1_slack14.2.txz
rm -rf /tmp/sudo-1.9.5p2-x86_64-1_slack14.2.txz

 

You can also append this to your 'go' file to install it on every reboot.

 

I know this is only a temporary solution but it's a solution that works.

After that you can issue 'sudo -V' in the terminal and you will see that you now have sudo 1.9.5p2 installed.

 

(Btw the package is from the official Slackware repo)

 

 

 

EDIT: Wrote a quick Plugin if this is what you are after, it will do basically the same and you don't have to edit anything (works only from Unraid version 6.8.2 to 6.9.0rc2):

https://raw.githubusercontent.com/ich777/unraid-sudo-patch/master/CVE-2021-3156.plg

 

 

Got an error running the plugin:

 

-----------------Downloading sudo 1.9.5p2, please wait...!---------------------
-----------This could take some time, please don't close this window!----------

-----ERROR - ERROR - ERROR - ERROR - ERROR - ERROR - ERROR - ERROR - ERROR------
------------------------Can't download sudo 1.9.5p2-----------------------------
plugin: run failed: /bin/bash retval: 1

 

1 hour ago, shrmn said:

Got an error running the plugin

Are you sure that the plugin can access the internet, have you some kind of PiHole or any other AdBlocker installed?

Are you able to download this package on your local computer: Click

 

EDIT: Tried it now and it works just fine. On which Unraid version are you?

It occurs to me that it might be important that docker containers are built to incorporate this fix?

This clearly falls within the bounds of the release methodology. I appreciate the conflicting pressures and associated costs but its time, 332 days between security releases is pushing it a bit.

 

  

On 9/2/2015 at 6:11 PM, limetech said:

At present we are maintaining two code branches:  latest stable and development.

 

The latest stable is always the first entry listed under Stable Releases on the website Download page.  The development releases are only publicized in the forum Announcement board.

 

If a relevant Slackware Security Advisory package update becomes available (or other kind of security update), we update both the latest stable and development branches.  For the latest stable branch, we then increment the patch level of the release version (the third digit) and publish the new release as soon as practical.  Other critical bug fixes may also trigger publishing another latest stable patch release.

 

Of the stable releases listed on the Download page, only the latest stable will be updated.  That is, we do not maintain multiple old stable releases at this time.  Updates are free and users are encouraged to keep up-to-date.

 

For the development branch, an updated release may or may not be published at the same time as the new stable release, but any package updates or bug fixes which go into latest stable are first integrated into development and tested.

 

Anyone who discovers a security-related issue is encouraged to post here so that we can integrate necessary patches in a timely manner.

 

On 2/1/2021 at 6:22 PM, NAS said:

This clearly falls within the bounds of the release methodology. I appreciate the conflicting pressures and associated costs but its time, 332 days between security releases is pushing it a bit.

 

  

 

 

I wouldn't expect anything before 6.9... Smh.