unRate

Members
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

14 Good

About unRate

  • Rank
    Newbie

Recent Profile Visitors

1263 profile views
  1. 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.
  2. 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 engineer
  3. 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
  4. Unraid is shipping vulnerable packages, some fixed over a year ago. Where's the security updates?
  5. 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. Project: https://www.vusec.net/projects/blindside/ Paper: https://download.vusec.net/papers/blindside_ccs20.pdf
  6. Abusing Docker containers for privilege escalation
  7. Which does happen. https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/
  8. 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
  9. 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 p
  10. 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 extens
  11. 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.
  12. My number 1 wish is better security https://forums.unraid.net/topic/80192-better-defaults/
  13. 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 o