Jump to content
We're Hiring! Full Stack Developer ×

unRate

Members
  • Posts

    50
  • Joined

  • Last visited

Recent Profile Visitors

2,391 profile views

unRate's Achievements

Rookie

Rookie (2/14)

15

Reputation

  1. 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.
  2. 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 module https://portswigger.net/daily-swig/critical-samba-flaw-presents-code-execution-threat
  3. 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.
  4. 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.
  5. 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.
  6. Unraid is shipping vulnerable packages, some fixed over a year ago. Where's the security updates?
  7. 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
  8. Abusing Docker containers for privilege escalation
  9. Which does happen. https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/
  10. 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.
  11. 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.
  12. 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.
×
×
  • Create New...