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.

Comments

Re:Good ol' 777

[MisterSquid]

Unix doesn't help much. I mean if apache can't read /home/me/www/path/to/index.html the OS isn't going to tell you its because of the permissions on /home. Meanwhile you have given up and gone chmod -R 777 /

Actually, both the browser and the Apache log will tell you it's a permissions issue. Go to the root of /home and either add the Apache user to the group that has access to "/home/me/www/path/to/index.html" or change the group access to Apache's user.

Once the group is correct, change the permissions to g+r if necessary.

Taking the 15 seconds to properly set permissions when you know the issue is a permissions issue (otherwise why would chmod 777 fix the issue) really is just too easy not to do.

Also, use your signal lights!

Re:not great, but probably not very important eith

[benjymouse]

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.