Sloppy File Permissions Make Red Star OS Vulnerable
An anonymous reader writes: Red Star OS Desktop 3.0, the official Linux distro of North Korea, which recently found its way onto torrents and various download sites in form of an ISO image, is interesting for a number of reasons, including its attempt to look like commercial operating systems (currently OS X, earlier versions mimicked the Windows GUI). Hackers are also poking Red Star for security vulnerabilities. An pseudonymous researcher noted in a post to the Open Source Software Security (oss-sec) mailing list, that the OS has one significant security hole: Red Star 3.0 ships with a world-writeable udev rule file /etc/udev/rules.d/85-hplj10xx.rules (originally designed for HP LaserJet 1000 series printers) which can be modified to include RUN+= arguments executing arbitrary commands as root by Udev. In the post he also mentions how the older Red Star 2.0 shipped with another schoolboy mistake: /etc/rc.d/rc.sysinit was world-writeable.
Whenever I see devs take the stupid shortcut of "chmod 777" I wonder what is the brain drain for these "professionals" that they can't figure out how to enable make use of "chown root:admin" and then "chmod g+x", or whatever's the appropriate level of permissions for the task at hand.
How can developers be so lazy and so security naive? It's like using signal lights when driving. Just do it because it makes for good habits.
blog
Awesome! At last a way to hack North Korea and steal all their... valuable things?
lucm, indeed.
Is this OS for the NK government use, or for use by the people in NK.??
If it's for the people I'm not surprised they made it easy to gain access...
Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
I hear a CD-R and a balloon were used.
And still the US government would have us believe that NK has a cadre of "elite hackers" responsible for Sony instead of the much more plausible and believable "inside job" by disgruntled employees -- especially as it would have taken months to download the terabytes of data that they claim was stolen.
I do not fail; I succeed at finding out what does not work.
This kind of exploit, a local privilege escalation exploit, used to be very significant, but is significant in a declining number of cases, as old-style Unix multiuser systems are a smaller and smaller proportion of systems.
An attacker who has exploited a Firefox vulnerability (there are still many found and patched each month) is running as a *local user* on your machine. Trying to explain these types of vulnerabilities away is disingenuous, if not downright complacent.
Unix/Linuxs permission system is 70-era bit-saving stupid. There is no other way to put it.
While this is clearly a mistake by someone packaging the distro, they were certainly not helped by a system where you cannot adequately express permissions. ACLs are available, but they are still kludges and they fell like a bolt-on with many tools still not recognizing them.
When a developer meets the limit of what can be expressed with a single-group me-us-everybody, he will often look for the path of least resistance. Unfortunately that is often relaxing permissions along the coarse-grained me-us-everyone, often ending up with everyone as in this case.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Some alternatives sound nice but fail horrificly when the come in contact with people, especially the ones that let any people within a group grant access to others with zero oversight. Within a short period of time with such a "everyone can grant or deny access" scheme you end up with almost everything wide open and occasional calls when the paranoid have locked themselves and everyone else out of something and forgotten the password - and it's typically something business critical (as in people need to get to it so they can do their job) but not actually sensitive with only a few people normally allowed to get to it. So the superuser is locked out - what do you do? Well such things are normally not well thought out in any way at all so you crack in with ease, especially since you have full access to the hardware, which kind of makes the whole idea of having permissions that lock out the superuser look pretty silly doesn't it?
So while user/group/all looks simplistic and kind of sucks in some cases there's nothing else that's really shown itself to be good enough to gain traction apart from where mandated by a vendor.
Saw that - first day at a new site and the developer that had been looking after things rebooted both the primary domain server and secondary domain server at the same time in the middle of a working day, for some trivial fix that didn't need to be done immediately and probably didn't even need a reboot. Of course they were also serving most of the files and all the printing as well. It's a mindset not a skillset. He knew what would happen but there was a fix for something so it had to be done NOW so he could get it out of the way without having to worry about it later. Consequences didn't matter, after all the new guy was there to take all the angry phone calls.
The old POSIX compliant user-group-others model does have some limitations. The non-root user can't arbitrarily add another individual user to have access or deny access, and only root users or site admins have access to create new groups. In the older systems, such as in UNIX's /etc/group and /etc/passwd, groups cannot contain other groups directly and there's a maximum line length on the number of characters in the "/etc/group" line. This gets quite awkward if you have hundreds of members of a group, or want to be able to say "all members of this group, *except* this one account, should have access to this". It means you have to add a new group and reset all files to owned and managed by that group: it can become painful to administer.
When compared to the obscure rat's nest of ownership in NTFS, however, I can see why the old POSIX ACL's have remained in use. And let's make not be confused, in the Windows world it is _extremely_ common to leave file ownership profoundly broken.