unRate
-
Posts
50 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by unRate
-
-
On 2/1/2022 at 8:35 PM, Meowcat285 said:
I feel like this is a issue that needs a patch in the next few days, not next few weeks
Then you need to be using a proper Linux distro :)
-
A newly discovered critical vulnerability in Samba could allow remote attackers to execute arbitrary code as root on affected installations.
All versions of Samba prior to version 4.13.17 are vulnerable to the heap overflow memory handling vulnerability – providing they are running the flawed VFS modulehttps://portswigger.net/daily-swig/critical-samba-flaw-presents-code-execution-threat
-
On 4/7/2021 at 8:46 PM, limetech said:
Unraid OS has come a long way since originally conceived as a simple home NAS on a trusted LAN. It used to be that all protocols/shares/etc were by default "open" or "enabled" or "public" and if someone was interested in locking things down they would go do so on case-by-case basis. In addition, it wasn't so hard to tell users what to do because there wasn't that many things that had to be done. Let's call this approach convenience over security.
Now, we are a more sophisticated NAS, application and VM platform. I think it's obvious we need to take the opposite approach: security over convenience. What we have to do is lock everything down by default, and then instruct users how to unlock things.
I'm pleasantly surprised to see you officially acknowledging this. This is definitely a step in the right direction. Looking forward to follow how "security over convenience" will be implemented.
-
Sure lets expose €%*@!*/# root to the internet. What could possible go wrong?
Everyone advises against root login and not using key-pairs via SSH, and you want to allow your users — which by your own implications are incompetent sysadmins — to access root over https?
You should at least use better defaults and apply the "Principle of least privilege" with layered security, before even considering rolling out remote access en masse. – Let alone using €%*@!*/# root passwords.
As a reference take a look at the effort put in to secure cockpit-project by their engineers.
I really can't fathom this nonchalant security mindset, hence the frustration.
-
1
-
-
On 2/15/2021 at 2:09 PM, raidfish said:
Has any of this been resolved since may 2019? Asking for a friend considering a purchase and trying to get an idea as to how security focused unraid is.
Nope...
-
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.
-
On 12/16/2020 at 4:22 PM, NAS said:
Whilst it is not ideal that the poster did not follow normal security reporting etiquette it is clear there is an issue and it is off our own making.
To be honest I find it kind of insulting, that you insinuate than I'm in the wrong. Had I been reporting an unknown exploit like this in the open I would have understood your response. But the CVEs I'm talking about are by their nature public knowledge... And some has been for over a year!
Now we can agree that it certainly doesn't look good that I have to remind you of security updates... But that is entirely different from leaking exploits in a public forum, and could have been avoided by staying on top of very basic security.
Your link to your Release methodology and excuses of bad habits doesn't help secure your customers unraid boxes. I'm disappointed in Limetech's mentally towards security in general. With this incident on top of the nonchalant attitude and implementation of security, it's definitely time to find another solution for my server.
-
Unraid is shipping vulnerable packages, some fixed over a year ago. Where's the security updates?
-
1
-
-
Given a simple buffer overflow in the kernel and no additional info leak vulnerability, BlindSide can mount BROP-style attacks in the speculative execution domain to repeatedly probe and de-randomize the kernel address space, craft arbitrary memory read gadgets, and enable reliable exploitation.
QuoteIn addition to the Intel Whiskey Lake CPU in our evaluation,we confirmed similar results on Intel Xeon E3-1505M v5, XeonE3-1270 v6 and Core i9-9900K CPUs, based on the Skylake, KabyLake and Coffee Lake microarchitectures, respectively, as well ason AMD Ryzen 7 2700X and Ryzen 7 3700X CPUs, which are basedon the Zen+ and Zen2 microarchitectures. Overall, our results con-firm speculative probing is effective on a modern Linux system ondifferent microarchitectures, hardened with the latest mitigations
Project: https://www.vusec.net/projects/blindside/
Paper: https://download.vusec.net/papers/blindside_ccs20.pdf
-
-
On 9/13/2019 at 7:31 PM, bonienl said:
It shouldn't be possible to "break out" of a container and as far as I know this isn't possible.
Otherwise it will be a security vulnerability of Docker itself.
Which does happen. https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/
-
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.
-
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.
-
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.
-
2
-
-
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.
-
My number 1 wish is better security https://forums.unraid.net/topic/80192-better-defaults/
-
6
-
-
While the current system is great for the average home network as a media server storing non-critical and non-confidential information on a private network, with a few changes, it could be ready for so much more...
Where I'm coming from: I'm new to unraid, and I am a long time Linux-user with widows as a side OS I avoid as much as possible. Currently I've been setting up a VFIO system, and because I won't just be using it to store media but to actually be my daily driver, I have certain security concerns with the current default configurations.
The following is a list of changes I've compiled, largely from http://kmwoley.com/blog/securing-a-new-unraid-installation/ and somewhat ordered by importance:
- SMB 1 disabled by default
- FTP and Tellnet disabled by default
- HTTPS enabled with a self-signed cert out of the gate (love the cert authority setup though!)
- make it more clear how to encrypt new drives (can't choose to encrypt when adding the device, has to be changed in the default filesystem setting)
- new shares not exported by default, and when exportrd, Private by default
- Don't export the USB boot media!!! (At least not by default and add an are you sure if you try to enable it)
- firewall such as UFW installed and enabled by default with only TCP port 80 and 443 set to LIMIT and whatever SMB uses opened. GUFW could be pulled from for the GUI. And providing quick check boxes for common ports would make it easy, possiblity auto enabling when you enable a core service.
- Docker Isolation through Linux namespaces / subuids
- allow tagging more shares for direct Linux VM mounting to prevent the need to pass through /mnt/user
- better multiple-user support, it's a server, right? So people other than root should be able to ssh in and access the UI; ideally root login would be disabled with use of a wheel group instead
- don't use 777 permissions by default, ideally users + groups, but at a minimum there is no reason for most things to be read, write, and execute by default!
- support for openvpn
- support for multiple different encryption keys
And add other lurking issues to this. Even if you're not exposing a system to the public internet, a lot of these things can still cause problems if the system is up 24/7. There is no such thing as a "friendly environment" outside air-gapped systems, and my daily driver will definitely not be air gapped.Anyway, if you've made it this far and feel like this is a list of complaints, I'm sorry. I do like unraid and I already feel excited for where it's going.
-
4
-
-
just use nfs?
-
-
Disable the creation of .DS_store on network drives (Client side)
defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true- Log out/in to take effect
Disable the creation of all ._ files (Server side)
- Stop the array
-
Go to Smb settings & add the following to the "Samba extra configuration" field
veto files =/._*/.DS_store/Additional files can be vetoed if needed, just remember a trailing "/"
-
1
-
Just make a share for stuff you want on ssd and set to use cache only
-
1 hour ago, Ockingshay said:
it is self hosting, but i'll give it a go.
is there a preference to next cloud or own cloud?
nextCloud definitely. It's was hard forked due to ownCloud investors being all about $$.
nextCloud have all the core developers and the original founder from ownCloud. They are self-sufficient, fully FOSS and have no outside investors to plea$e.
https://www.phoronix.com/scan.php?page=news_item&px=OwnCloud-Is-It-An-Exodus
-
What is wrong with NextCloud?
-
This is really slick and very easy to customize!
Any change you'll update it for the recently updated Webgui?
New Remote Vulnerability for Samba (CVE-2021-44142 & CVE-2022-44142)
in Security
Posted
Slackware is a Linux distro indeed. But unless you run unraid on top of vanilla Slackware yourself, then unraid is considered an "Appliance" by Limetech. Which translates to "We don't have to do security patches, nor do we need users, DAC, just run everything as root"
They are not going to patch this. It will be updated in the next RC at best. These CVE's are already 4 months old!
What I meant by my initial comment about using a proper linux distro is that if you care one bit about security use something that gets regular updates. e.g., Proxmox, TrueNAS scale, vanilla Linux, etc.