Critical Security Vulnerabilies Discovered


limetech

Recommended Posts

tldr: If you are running Unraid OS 6 version 6.8.1 or later, the following does not apply (mitigations are in place).  If you are running any earlier Unraid OS 6 release, i.e., 6.8.0 and earlier, please read on.

 

On Jan 5, 2020 we were informed by a representative from sysdream.com of security vulnerabilities they discovered in Unraid OS.  Their report is attached to this post.  At the time, version 6.8.0 was the stable release.

 

The most serious issue concerns version 6.8.0.  Here they discovered a way to bypass our forms-based authentication and look at the contents of various webGUI pages (that is, without having to log in first).  Then using another exploit, they were further able to demonstrate the ability to inject "arbitrary code execution".  Someone clever enough could use this latter exploit to execute arbitrary code on a server.  (That person would have to have access to the same LAN as the server, or know the IP address:port of the server if accessible via the Internet.)

 

Even in versions prior to 6.8.0, the "arbitrary code execution" vulnerability exists if an attacker can get you to visit a webpage using a browser that is already logged into an Unraid server (and they know or can guess the host name of the server).  In this case, clicking the link could cause injection of code to the server.  This is similar to the CSRF vulnerability we fixed a few years ago.

 

In summary, sysdream.com recognizes 3 vulnerabilities:

  1. That it's possible to bypass username/password authentication and access pages directly in v6.8.0.
  2. That once authentication is bypassed, it's possible to inject and have server execute arbitrary code.
  3. That even if bug #1 is fixed, #2 is still possible if attacker can get you to click a link using browser already authenticated to your Unraid server (6.8.0 and all earlier versions of Unraid 6).

 

Mitigations are as follows:

 

First, if you are running version 6.8.0, either upgrade to latest stable release, or downgrade to an earlier release and install the sysdream mitigation plugin.  We are not going to provide a mitigation plugin for 6.8.0.

 

If you are running any 6.6 or 6.7 Unraid release, the best course of action is to upgrade to the latest stable release; otherwise, please install this mitigation plugin:

https://raw.githubusercontent.com/limetech/sysdream/master/sysdream.plg

 

This plugin will make a small patch to the webGUI template.php file in order to prevent arbitrary code execution.  This plugin will work with all 6.6.x and 6.7.x releases and should also be available via Community Apps within a couple hours.

 

We are not going to provide a mitigation for Unraid releases 6.5.x and earlier.  If you are running an earlier release and cannot upgrade for some reason, please send us an email: [email protected].

 

I want to thank sysdream.com for bringing this to our attention, @eschultz for initial testing and fixes, and @bonienl for creation of the sysdream mitigation plugin.

 

I also want to remind everyone: please set a strong root password, and carefully consider the implications and security measures necessary if your server is accessible via the Internet.

 

Finally, try and keep your server up-to-date.

 

VULNERABILITY_DISCLOSURE.pdf

  • Like 10
  • Thanks 14
Link to comment

Available within CA.  Either go to the new apps section or search for sysdream or limetech.   If it doesnt appear, then you're not running a version of unraid which the plugin will work on (or isn't needed - 6.8.1 / 6.8.2)

Edited by limetech
fix typo in plugin name
  • Like 2
  • Thanks 3
Link to comment
On 2/6/2020 at 5:35 PM, Dazog said:

@limetech

 

Not to be that guy but are we expecting a 6.9 RC soonish?

 

I cannot use 6.8 due to BTRFS issues on 4.19 kernel.

 

I am currently on 6.8RC7 due to kernel 5.3.

 

Thanks again.

I second this. I'm sure there are a LOT of us still on 6.8-RCx for one reason or another. I thought releasing 6.9RC series at the same time as 6.8 stable was a great plan, but it's almost 2 months later.

  • Thanks 1
Link to comment
1 hour ago, unRate said:

While I appreciate the transparency, this is exactly why running everything as root is a very bad idea. Is this request ever going to get at least a statement from limetech?

 

Maybe it is time to build a proper Linux server and utilize it's security features.

Unraid is an appliance.  There is only one user: root.  We can rename to "admin" but it's still root.  There are not traditional user logins.  Users are only used to validate SMB connections.  Running as non-root would not have prevented this vulnerability which btw, was a couple 1-line bugs.

 

re: the request: we have a blog post that talk about this:

https://unraid.net/blog/unraid-os-6-8-2-and-general-security-tips

 

Sure I can go reply in there...

  • Like 2
  • Thanks 1
Link to comment
15 hours ago, limetech said:

Unraid is an appliance.  There is only one user: root.  We can rename to "admin" but it's still root.  There are not traditional user logins.  Users are only used to validate SMB connections.  Running as non-root would not have prevented this vulnerability which btw, was a couple 1-line bugs.

 

re: the request: we have a blog post that talk about this:

https://unraid.net/blog/unraid-os-6-8-2-and-general-security-tips

 

Sure I can go reply in there...

Uhm... I feel like you are evading the question.


With the tunnel vision of "Running as non-root would not have prevented this vulnerability" then yes the attacker would still have been able to bypass your authentication, and do arbitrary code execution. The big issue is that since the server is running as root, well he basically have unrestricted root/superuser access.

Had the process been in a group with less permissions, further exploiting and privilege escalation would be needed to pwn the server...

 

Throwing the core UNIX discretionary access control, and its extensions out the window is mind-boggling at best.

 

"Unraid is an appliance" what does that even mean in this context?

 

Regarding the blog post, it aids getting the best out of the current state of unraid security. It does nothing in addressing the essence of the original request; Namely is limetech ever going to implement DAC, MAC, SELinux, sudo, and file permissions, etc. - or should we move to another Linux implementation that does?

 

I hate to do this, but it's done with tough love and in the interest of the average Unraid user.
3 years ago, you said "We take security very seriously" in a response to "I guess spending time adding eye-candy and stuff like that is more profitable than mundane security stuff, which is a very short-sighted approach."

 

You have now hired a full-time web developer, with design and marketing experience. While arguably nothing has been done to effectively improve security at the core.

 

Edited by unRate
  • Like 2
Link to comment
5 hours ago, unRate said:

"I guess spending time adding eye-candy and stuff like that is more profitable than mundane security stuff, which is a very short-sighted approach."

I think you are a bit short sighted too.

In the past years several updates were done to improve security and today's level certainly has improved a lot.

Here is a list top of my head, and likely I am forgetting some ...

 

- Regular package upgrades to address reported CVEs

- Address CSRF attacks

- Address XSS attacks

- Added SSL/TLS support

- Added SSH support

- Added disk encryption

- Verify path validity when executing scripts

- Disallow direct script execution from the USB device

- Improved user input checks throughout the GUI

  • Like 2
  • Thanks 1
Link to comment
1 hour ago, bonienl said:

I think you are a bit short sighted too.

In the past years several updates were done to improve security and today's level certainly has improved a lot.

Here is a list top of my head, and likely I am forgetting some ...

[...]

First off that comment wasn't made by me, it was part of a reasonable and well written, similar concern from another user 3 years ago. Knowing now that limetech has hired a full-time web developer, (presumable the man behind the fancy new landing page, marketing and whatnot) while not prioritizing security, that comment resonated with me...

 

When I say "[...] arguably nothing has been done to effectively improve security at the core." I mean that nothing has really been done to make the underlying Linux system more secure than it was 3 years ago. (DAC, MAC, SELinux, sudo, and file permissions, etc...)

 

I'm not saying that I don't appreciate the various CVE patches, but that's not the point neither the problem.

Edited by unRate
Link to comment
34 minutes ago, unRate said:

while not prioritizing security

This is a load of B.S.  While I appreciate the sentiment of your post (wanting to improve security), it is not helpful to simply complain.  What is helpful is to point out specific attack vectors that we can address.  Unraid is rapidly evolving from a simple NAS mainly used by tech-savvy home users to a more general platform with a wider range of users.  It used to be the introduction of some bug that causes customer data loss that kept me up a night.  These days, having a bug that presents a security risk is far more worrisome.  So don't tell me we don't take security seriously.  That said, there is a trade-off between making the server easily accessible for a first-time user vs. locking it down so tight no one can figure out how to even get in.  I'll give you an example.  By default we export the 'flash' share as a public share.  Some people's hair catches on fire because of this.  But the reason it's done this way is that after a user creates a bootable USB flash a very simple test is to see of the 'flash' share shows up in network explorer.  There are other reasons it's handy to have this public for at least some amount of time.  These days we have an icon next to the flash share if it's public, where rollover warns about this.  Moving forward we are developing an initial configuration wizard that will guide a user in setting up the level of security appropriate for them.

  • Like 6
  • Thanks 2
Link to comment
7 hours ago, limetech said:

This is a load of B.S.  While I appreciate the sentiment of your post (wanting to improve security), it is not helpful to simply complain.  What is helpful is to point out specific attack vectors that we can address.  Unraid is rapidly evolving from a simple NAS mainly used by tech-savvy home users to a more general platform with a wider range of users.  It used to be the introduction of some bug that causes customer data loss that kept me up a night.  These days, having a bug that presents a security risk is far more worrisome.  So don't tell me we don't take security seriously.  That said, there is a trade-off between making the server easily accessible for a first-time user vs. locking it down so tight no one can figure out how to even get in.  I'll give you an example.  By default we export the 'flash' share as a public share.  Some people's hair catches on fire because of this.  But the reason it's done this way is that after a user creates a bootable USB flash a very simple test is to see of the 'flash' share shows up in network explorer.  There are other reasons it's handy to have this public for at least some amount of time.  These days we have an icon next to the flash share if it's public, where rollover warns about this.  Moving forward we are developing an initial configuration wizard that will guide a user in setting up the level of security appropriate for them.

I'm not "simply complaining" I'm giving you my raw feedback on what it looks like to me from the outside. At the same time I'm looking for answers.

I have asked you specific questions, a few posts above, which you conveniently danced around. Questions which link to past discussions on "specific attack vectors" 

 

By reading the forum, it is clear that I'm not the only one that have been concerned with the security of unraid for years...
These specific weak points have been pointed out, none of them have been addressed...


I'll ask again, is limetech going to make use of the Linux security features (Discretionary Access Control, default firewalls, SELinux, sudo, and file permissions, to name a few.), or should those who give a shuck move to another Linux implementation that does?

 

I would very much appreciate an answer so that I can make a decision. Thank you.

 

Edited by unRate
Link to comment
2 minutes ago, unRate said:

I have asked you specific questions, a few posts above, which you conveniently danced around.

I haven't "danced" around anything, sorry if it appears like that.

 

2 minutes ago, unRate said:

Discretionary Access Control

How does this apply in an Unraid server environment?

 

3 minutes ago, unRate said:

default firewalls

Yes this is something we're looking at.

4 minutes ago, unRate said:

SELinux

why?

4 minutes ago, unRate said:

sudo

why?  There is only one user: root

 

5 minutes ago, unRate said:

file permissions

You can set file permissions however you want using standard linux command line tools.  Again, what are you trying to accomplish?

 

We do have plans to introduce the idea of multiple admin users with various roles they can take on within the Management Utility.  For example, maybe you create a user named "Larry" who only has access to the Shares page with ability to browse shares only they have access to.  However this functionality is not high on the list of features we want/need to implement.

 

Earlier you were confused by my term "appliance".  What this means is the server has a single user that can manage the box.  If you don't have the root user password, all you can do is access shares on the network that you have permission for, and access Docker webUI's - but most of these have their own login mechanism.

 

Things like the flash share exported by default, new shares public by default, telnet enabled by default, SMBv1 enabled by default, etc. are all simplifications to reduce frustration by new users.  Nothing more frustrating that creating a share and then getting "You do not have permission..." when trying to browse your new share.  We are trying to reduce the swearing and kicking of dogs by new users just trying to use the server.

 

Eventually everyone needs to be more security conscious - and in that spirit we are working on "wizards" that will guide a user to setting up the correct settings for their needs.

 

I hope this starts to answer some questions and sorry if I came across flippant to your concerns, but trust me, security is a foremost concern and to have someone imply otherwise ticks me off to be honest.

  • Like 13
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.