Slashdot Mirror
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
Ah those silly world-writeable schoolboys and their... antics.
http://forum.xda-developers.co...
Such as, who leaked the ISO out of N.Korea?
Life is not for the lazy.
Ah, the devil.
Awesome! At last a way to hack North Korea and steal all their... valuable things?
lucm, indeed.
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. In all likelihood anyone with a user account on a North Korean computer is pretty heavily monitored, and ensuring nobody violates policy can be enforced by "other means" than Unix permissions.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Hell, IMO if TAILS were serious they would roll a hardened Gentoo distro (or OpenBSD) without so many packages and without so many odd additions, including:
1) The 'Whisperback' package /usr/local/sbin and removing all traces of debugging scripts - go ahead and read both files on TAILS and question why a distro such as TAILS needs these.
2) Not shipping with 'autotest_remote_shell.py' and 'do_not_ever_run_me' in
Don't suggest liberte linux, development has stalled since it's first version a long time ago. Don't suggest the OpenBSD Anonymous Tor CD, it's outdated and won't connect to the Tor network.
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 presume there will be few job openings for adventurous Linux gurus @ NK atm.
Now that the world is "interested", every time these things come to public, the person responsible for the clitch, will be without his/her head.
I'm talking about "Hacker Fantastic", Ars, and /. Yeah, let's help NK as much as we can by fixing their shit for them.
I am Audience.
So it's a Linux distro for personal use on a single desktop, where sloppy permissions don't matter. Other similarly purposed distros have similarly lax permissions. Granted I haven't used it for a few years, but I seem to recall seeing the same kind of issues with PCLinuxOS. No big deal, just don't install it on a server.
Very significant in the distant past before personal computers, maybe. Used to be very insignificant on Windows 95 and MacOS 9 too. Only recently is everything a complete multiuser system, with only one user.
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.
And I don't mean North Korea.
NK "leaks" the latest version of their preferred OS to the rest of the world, and western researchers probe it for security problems and provide feedback FOR FREE!
C'mon guys! Think out of your narrow box, occasionally?
Nearly like most of the PHP installations, no?
As long as this culture doesn't change, we'll continue to see gruesome hacks.
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*
You fail to explain what's wrong about Trep's purely innocent observation.
You then label the Unix permissions as "stupid" without bothering to explain why you call it that.
You then point to a lack of "adequate" features that you've failed to explain or why you think they're so important.
You then claim a mysterious "limit" that you don't bother to explain that somehow magically causes developers to make mistakes that have nothing to do with the system itself.
I would suggest you educate yourself before you criticize something that you very clearly do not understand.
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.
If you understood the interplay between the flat out UGO rights and group membership maybe, just maybe you wouldn't take the opportunity you did to bash Unix/Linux file permissions.
Why do Americans keep on writing "an" instead of "a" all the time? Is it that fucking difficult to understand? Your nation is truly fucked. "An pseudonymous researcher" indeed. Idiot.
Clearly they're cultured people, despite lacking basic computer skills and intelligence in general.
I was wrong about them!
.
.
As the original author of mac menubar for GTK/GNOME (it's gnome right? not KDE?), I must say I feel really good about that. Long Live the Kim!
Someone found and posted a security home in the official North Korean OS? I suspect that one of the OS's developers (and his family) is about the receive a free lifetime stay at Klub Kim.
Just because you are paranoid does not mean that no-one is out to get you.
lernin north korean for dere haxxin
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.
An access control system where everyone (with access?) can grant access to others sounds bad. However, I don't think that's the only alternative to me-us-everyone rwx. In fact, I don't know that such a system that exists at all. You usually needs to be the owner of a resource (or in the "owners" group) to grant privileges in a DAC system. Some systems also allows owners to grant specific rights on the security attributes to non-owners - i.e. the right to grant access.
Within a short period of time with such a "everyone can grant or deny access" scheme you end up with almost everything wide open
How about a system where only owners or designated security administrators can grant/deny access? The issue here was that a developer *wanted* access to a file from a non-owner and non-group member account. Lacking finer grained ACLs, that leaves only "everyone".
It sounds like you believe that discretionary access control (DAC) is the alternative to Unix filesystem permissions. It's not. Unix filesystem permissions is itself a DAC system, albeit a very limited one. DAC only means that the owner of a resource (or a designated security administrator of a resource) can grant access to others. Because the creator of a file is often considered the owner, creators can often grant access to whom they choose.
However, if a user has been granted "read" access to a resource he can usually not grant it to someone else, unless he is the owner. Do you know of a system where, by default, you can grant the same permissions that you have been granted?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
"Is this OS for the NK government use, or for use by the people in NK.??"
In a country with most of the population starving and with a few cell phones in border areas to make calls using chinese ... what is the chance of anything capable of running "Red Star OS"
cellular networks, a country where you and your entire family can be arrested and taken to a death camp just because
you didn't cry hard enough when Kim-Jong-Il died
outside of a government facility?
Of course this is for their government and for the privileged. KJFUN surfs full spectrum anal domination porn sites
with Red Star OS. (I tell you that kid is such a pathetic loser, they should get rid of him and use his sister.)
Now the only thing that might be is... there might be different variants of RSOS ... one for KJFUN .. one for his "friends" ... OH and one variant
one for his enemies and a bunch of other variants for use in libraries, technical institutions etc.
for leaking to the west, i.e. what you just downloaded.
> Unix/Linuxs permission system is 70-era bit-saving stupid. There is no other way to put it.
It's extremely simple, and extremely fast to handle computationally. Those "bit-savings" come out of every file system access, including pipes and symlinks and block and character devices. When a developer "meets the limit of what can be expressed with a single-group me-us-everybody", it's usually a sign that they're doing something fundamentally wrong and trying to invent special groups of their own on the fly. It can also be the case that they're trying to allow access for one other person at a time, which I acknowledge can be problematic if you don't have easy access to create or remove user groups.
There are network based file systems that support more complex Access Control Lists, ACL's. NFSv4, for example, supports it. But it also tends to be confused, abused, and unstable in use.
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.
Application level security would be an improvement. An application should be restricted to its own files and directories unless user gives explicit permission.
What about whonix?
The owner of a file doesn't tend to matter much in the Windows world, only who has Full Control rights to it
I am a viral sig. Please copy me and help me spread. Thank you.
Perhaps this kind of obvious vulnerability was deliberately introduced by North Koreans. Great job pointing it out and getting them killed for their call for help.
AppArmor is a good start toward this. It can only be configured by root though.
You've just managed to kill a few high profile devs in North Korea.
Good work gentlemen.
Which is why I wrote that many such things have fallen over when in contact with people - who tend to sort things in groups and have differing ideas of who should be in the groups. Conflicts develop of who should have access so it devolves into free for all for most and individual permissions for some. Maybe the military have something that works, but the sort of things that have been inflicted on office environments have not been enough of a success to demonstrate superiority as yet.
There's plenty of good ideas, but getting around the petty issues such as "Bob has access to Z and I've been here five years longer, why don't I have access even though I don't need it for my work" becomes difficult when multiple people have control over permissions.
In what way are ACLs a kludge? There are official tools to support them and proper system calls to manipulate them.
The biggest shortcommings are GNU tar and cpio not supporting them properly.
So who should own the text file? Vi? cat? grep? emacs? gcc?
So who should own the text file? Vi? cat? grep? emacs? gcc?
Those are applications which have nothing to do with ownership although the user must have permission to use them. It is the user who should own the file, text or otherwise.
The Unix permissions of "user", "group" and "other" are still valid even today. If you want a more fine grained permission solution then look no further than Access Control Lists which have been in use by Unix since the late 1980's and Linux since the early 1990's.
The big problem with ACL's is not the concept it is when users expect the System Administrator to manage ACL's for them. Even on the latest OS's be it Linux, MS Windows, VMS or Unix the same base Unix permissions are still in use with ACL's only used when there is a need.
There ain't no such thing as proprietary standards only proprietary formats. Standards are by definition open.
I was asking someone who believes applications should own files and that access control should be by application.
I find Unix permissions + ACLs to be adequate. Users tend not to understand them, so I frequently use default ACLs on directories.
http://www.otoanphuoc.vn/xe-ta...