Become a fan of Slashdot on Facebook

 


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

SecuriTeam Posts Paper on Mac OS X Vulnerabilities 85

Posted by pudge from the 3y3-0wnZ-j00 dept.
ehenning writes "SecuriTeam has posted a paper on some known vulnerabilities in Mac OS X. It lists methods for developing shellcode based on the PowerPC architecture. They note that there are similar vulnerabilities in Mac OS X and Darwin as in IA32 machines."
This discussion has been archived. No new comments can be posted.

SecuriTeam Posts Paper on Mac OS X Vulnerabilities More

SecuriTeam Posts Paper on Mac OS X Vulnerabilities

Comments Filter:

  • Link (Score:3, Informative)

    by vasqzr ( 619165 ) <`vasqzr' `at' `netscape.net'> on Wednesday September 03, 2003 @04:58PM (#6862784)

    Here's a link to the original article [securiteam.com].

  • Boooring... (Score:5, Informative)

    by andfarm ( 534655 ) on Wednesday September 03, 2003 @04:59PM (#6862804)
    No actual security issues here, just "shellcode" -- compiled assembly -- to do things like print messages, run /bin/sh, or reboot the machine. Unimpressive.

    • Re:Boooring... (Score:2, Insightful)

      by darkov ( 261309 )
      to do things like print messages, run /bin/sh, or reboot the machine. Unimpressive.

      That is, run /bin/sh as root. Which is very handy for me, since I forgot the admin password on my laptop and need to reset it.

      • Re:Boooring... (Score:3, Insightful)

        by Anonymous Coward
        Boot from your OSX install cd. You can change the password there.
      • Either:

        1. Reboot from the OS X install CD. Go to the file menu once the installer starts. You can reset your password there.

        2. Load up the netinfo manager and you can do the same thing if you're actually forgetting your root password and not the admin password. Just authenticate and reset the password.

        --T

      • Re:Boooring... (Score:2, Informative)

        by gabebear ( 251933 )
        actually this won't let you elevate your privleges, it will let you start bash or anything else as root if you can get this to execute from a buffer overflow from a program that ALREADY is running as root.

        The easiest way to get bash/tcsh running as root is to type "sudo su root" and then type your password, then if you want to change roots password you can type "passwd" and viola. This also works on other UNIXs that let you use sudo to execute anything.
      • Reboot holding down CMD-S. Or maybe that's CMD+S+U. It puts it in single-user mode.

    • Re:Boooring... (Score:2, Insightful)

      by gnuadam ( 612852 ) *

      Is it still unimpressive when you realize that these turn any remote exploit into a remote root exploit?

      Good thing apple is right on top of those patches, or I'd be a bit more worried.

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

        by andfarm ( 534655 )
        Nope. Not unless apache/ftpd/sshd runs as root. (Though, admittedly, sshd does... then again, it's been a while since the last exploitable hole there.) And anyway, anybody could put these bits of "shellcode" together with gcc and 5 minutes -- myself included.
      • Precisely where was the privelege escalation in the code?
        I see writes, and exec*s, but nothing that sets the (e)uid.

        The only clever thing about these kinds of things is how to avoid 0x00. However, when I saw someone's Alpha stack-smash (Oh's?) about 3 years ago, I realised that any RISC was as exploitable as any other architecture. This PPC one simply loads constant 0x00pq as 0x{00+gh}{pq+ij}, and then subtracts 0xghij. Nothing novel there. The alpha was more interesting as some of the vital instructions h
        • "The only clever thing about these kinds of things is how to avoid 0x00."

          Yea, that was interesting. I wonder if the processor designers should start checking the reserved fields in some of those instructions and throwing an illegal-instruction trap if they are non-zero. That would seem to make it more difficult to design these bits of code. Makes forward compatibility for object code more difficult too, I guess. (G5+reserved field checking might not run G6 code that defines some of those bits...)

          Iz
          • Avoiding zeroes is child's play.

            What's more interesting is how to avoid any non-alphanumeric characters. The x86 ISA permits xor, inc/dec, push/pop, and can be used to create (on the fly) any sequence of bytes, which can then be jumped to (so you don't do your computations in this restricted instruction set, you simply build the real program using it).

            I have no idea whether any RISC architectures can avoid non-alphanumeric characters in the opcodes.

            If they can then simply avoiding a few reserved fields s

  • Please Note.. (Score:5, Informative)

    by Toast ( 3221 ) on Wednesday September 03, 2003 @05:04PM (#6862864) Homepage
    The paper isn't talking about specific OSX vulnerabilities. It is just an exploration of writing shellcode for the Darwin OS on the PPC architecture, which hasn't gotten much coverage up 'til now.

    So far, we OSX users have been able to rely on security via obscurity.. Thanks to fink etc. we have the same vulnerabilities as other unix software, but the stock exploits (which are all sun/x86 targeted) just bounce off. B-root took the time to figure out some of the more fun snafus of PPC shellcode (lots of NULs due to the 32-bit alligned instructions mainly.)

  • Use this applescript instead ;) (Score:5, Funny)

    by daeley ( 126313 ) * on Wednesday September 03, 2003 @05:04PM (#6862875) Homepage
    tell application "System Events" to sleep

  • uh oh (Score:3, Funny)

    by Anonymous Coward on Wednesday September 03, 2003 @05:18PM (#6863042)
    Bring on the script kiddies!
    • Well.. I guess I just need to create a new program with a obious buffer overflow (static buffer), put it in a shared directory, set the UID to 0, then create a guest account, which I would share with the world because I enjoy getting hacked.

      On a more serious note, posting shell code out in the open will only encourage amateur crackers to try. The paper should just be shared within community of people researching computer security.

      I wonder if this was posted as a retalliation of all them mac news sites

  • I suppose this is something we must live with, but it is extraordinarily annoying to have to accept the security evaluation of a pseudonymous author.

    • Re:Who? (Score:3, Insightful)

      by bnenning ( 58349 )
      I suppose this is something we must live with, but it is extraordinarily annoying to have to accept the security evaluation of a pseudonymous author.


      Why does it matter who they are? You don't have to "accept" anything; they provide the code, which can be independently tested to see if their claims are accurate.

  • Vulnerabilities (Score:2, Interesting)

    by krisbrowne42 ( 549049 )
    You know, it might just be me, but it looks like those need to be run as Root, or be run on vulnerable setuid executables, to be effective.

    Just to put it in perspective.

  • Am I missing something? (Score:5, Interesting)

    by tuxedobob ( 582913 ) <tuxedobob@mac . c om> on Wednesday September 03, 2003 @05:59PM (#6863444)
    Okay, on page 6 he chown's the test program to root. Now, I just tried to chown something I own to root and it said operation not permitted. This is true in both tcsh and bash. It does of course work if you sudo, or start as root, but if you have root access, why write shellcode to give yourself root access on the same machine? Or is this covered after the first 12 pages?
    • Because when theres an exploit out that lets you 'run code as root', theyre usually talking about shellcode. feed it this and you get a rootshell.

    • Re:Am I missing something? (Score:1, Informative)

      by Anonymous Coward
      Yes, you are missing something, probably because the synopsis wasn't exactly clear on it.

      What the author covers in this document is how to leverage buffer overflows on the PowerPC architecture. Sort of a "see, you can do this on PowerPC too".

      Surely, no self-respecting geek presumed that buffer overflow exploits on OS X were not possible, but this is the first proof that they do exist.

      So what's the big deal about this news? Well consider that I could go and write a version of "Safari Enabler" which does l
      • During installation, I require that you provide your admin password.

        While it's small, don't underestimate this. My experiences with Windows have been through jobs, and it seemed like everything I needed to run required me to have Admin access WITHOUT PROMPTING*. On a home computer it's easy to see someone running something and giving it the Admin password, but they would have to have thought it was reasonable to do so - and have the password. (An excellent reason to set up each family member with thei

      • If you have a trojan that can get root privileges, why would you bother using any of the code given in the article? Just do it directly in the trojan

        All this article shows is how to write buffer overflow payloads, if you find a buffer overflow in a root process.

        Something else you can see from reading the (original) article are a few simple ways to make it harder to use such a payload - e.g. processing a system call could check that the sc operation was specified correctly. However, there are so many way

    • Yes - his test program was just that - a test. It shows that if a buffer overflow exists in an existing setuid program (e.g. sendmail) then the techniques explained in the article could be used to get a root shell.

  • Still can't see it... (Score:5, Interesting)

    by foniksonik ( 573572 ) on Wednesday September 03, 2003 @06:16PM (#6863589) Homepage Journal
    I still can't see script kiddies sitting down to do this type of hacking for any length of time... seems like they prefer instant gratification. Maybe if someone much more intelligent were to write up a few cracker's kits with a bundle of preset tools and whatnot... maybe then.

    As always, if someone REALLY wants to get in to your stuff, they will find a way. Locks and other security are really only targeted at vandals, not thieves.
    • Maybe if someone much more intelligent were to write up a few cracker's kits with a bundle of preset tools and whatnot... maybe then.

      You don't suppose that's why they call them script kiddies do you?
    • Regarding your sig:
      "the fittest species will be the one that presides over its own ELECTION"

      It seems that the electronic voting machine
      companies are owened by Republicans .....
  • I thought I was a pretty big geek, but that article looked like pure gibberish to me. ;-) I suspect that my local Mac User Group might have 2 or 3 members who know something about shell programming, but that's it.

    • 2 or 3? Wow. I'm not sure where you're from. The Mac User Group here is a total blue hair (read over 65) crowd.

      • Re:Eh? (Score:3, Funny)

        by Alex Thorpe ( 575736 )
        Those 2 or 3 would also be members of the local UNIX User Group. Don Ellis, anyway. But the MUG does have a lot of grey hair. I'm the youngest regular attendee at 32, and my father is the Treasurer.

    • Eh?

      This is nothing to do with shell programming, this is about getting _to_ a shell from within an arbitrary (exploitable) program (by exec*-ing "/bin/sh").

      YAW.

  • I don't see why this made Slashdot (Score:5, Informative)

    by ZackSchil ( 560462 ) on Wednesday September 03, 2003 @07:25PM (#6864223)
    I guess Slashdot is just about as sensationalist as your average Dateline or 20/20. The truth of the matter is as follows for all of you who read the article but still didn't get it.

    The document contained bits of assembly code that do all sorts of nasty things once slipped into a system. The code could elevate privileges, stat/stop processes, or reboot the machine. It's scary stuff but nothing you should be alarmed or surprised about. Anyone could harm a machine by writing code, that part isn't difficult at all. I could make an Applescript that wipes out your home directory or masks its self as another application, asks for an admin password, then proceeds to wipe your whole HD and overwrite it with ASCII garbage. Creating malware isn't the problem at all. Do you follow me?

    What this guy did was create malware that could be slipped into a system remotely through another security exploit, a buffer overflow for example (a buffer overflow is the same type of bug that caused that whole OS X screensaver crashing nonsense a while back that was promptly fixed by Apple). The reason the article is not a reason for concern is that there isn't currently a well know exploit of this nature for someone to use the code featured in this article. The same "security flaws" exist in almost any modern computer system. The thing is, the code isn't the security flaw, an exploit that allows the code would be. The article names no such new exploit.

  • Apple is becoming popular (Score:4, Funny)

    by theolein ( 316044 ) on Wednesday September 03, 2003 @09:24PM (#6865061) Journal
    At first I had a bit of a wonder as to what all this assembly code was until I realised that it wasn't actual exploits, but ways to implement an exploit once you got past the vulnerability.

    The mere fact that someone has started posting this stuff on the net should be reason for all us OSX fans to rejoice: OSX is now popular enough that script kiddies and security types are starting to take notice of it.

    Truly a two edged sword.

  • For the Un*x junkies out there (Score:3, Interesting)

    by krray ( 605395 ) * on Wednesday September 03, 2003 @10:46PM (#6865533)
    I read through this. Read it again. Never did like assembly. Time and again it got back to the same thing it seems.

    Turning the set-user-id bit on. Yeah.
    $ cp /bin/sh /bin/root-shell
    $ chown 0.0 /bin/root-shell
    $ chmod u+s /bin/root-shell
    $ /bin/root-shell
    #

    Yeah, well, not really (anymore :). Back in the the day this was a _easy_ way to take over the AT&T 7300 Unix system lab. Get root on one machine -- and create a root shell. Dump it to a floppy and you were gHod. Mount it as any user on any machine and execute -- you're root.

    Today this shouldn't work (and doesn't per the example above). His "exploit" basically tricks the system into actually making it happen. The key is getting a controllable root suid file on the system....

    WITHOUT being asked for a password. Good luck. :)

    I can just write a shell script: sudo my_bad_script
    Email it off and hope people type their password when prompted. Too bad my users don't know root's password -- and they really have no need to be admin either. Benefits of company equipment...

    PS: I'd be willing to bet my other nut that this little buffer overflow trick, which is really useless, won't work anymore with the official Panther release.
    • Today this shouldn't work (and doesn't per the example above). His "exploit" basically tricks the system into actually making it happen. The key is getting a controllable root suid file on the system....

      His "exploit" isn't a full exploit.

      The point is, suppose you have a suid program which *is* vulnerable to a buffer overflow. Say they find another unchecked buffer in sshd. It's almost guaranteed to happen eventually. The question is, what code do you drop in the buffer? That's what he wrote.

      PS: I'd
    • "WITHOUT being asked for a password. Good luck. :)"

      No sweat. Since I have access to the machine (per your last exploit) I insert the Mac OS X install disk, reboot from the CD, and select "Reset Password" (paraphrasing here) to change the password for the admin accounts. It might even set the root password if enabled. If root isn't enabled, I boot back into the system I just cracked, enable root, and set the password. Even if you just have an admin password, you can install anything you want anywhere yo
      • No sweat. Since I have access to the machine (per your last exploit) I insert the Mac OS X install disk, reboot from the CD, and select "Reset Password" (paraphrasing here) to change the password for the admin accounts

        Exactly, if someone already has this kind of access to a machine, then why bother with all the other stuff?
        • The old saying still applies -- there is no security without physical security.

          You can stop the aforementioned "password reset" by applying the Open Firmware Password 1.0.2 [apple.com] patch. This patch alters the Open Firmware to require a password to change the boot device.

          With that said, someone with physical access to the machine can take the hard drive out, plug it into another mac as a secondary drive, and read all the data off the disk. Nothing short of disk-driver-level encryption can prevent that.

          If you w

  • 3. The opcode for sc (system call) is 0x44000002. However, bytes 2 and 3 of the opcode are reserved and therefore not used. With no other opcodes beginning with 0x44 or ending with 0x02 it is possible to use any none zero value for bytes 2 and 3 of the opcode without affecting its operation. The final opcode for 'sc' can therefore become: -

    sc .long 0x44ffff02

    It shouldn't be all that hard for Apple to make the 'sc' instruction handler check the other two bytes of the instruction and make sure that they'r

  • To repeat (Score:3, Insightful)

    by derubergeek ( 594673 ) on Friday September 05, 2003 @03:33PM (#6882131) Homepage Journal
    SecuriTeam has posted a paper on some known vulnerabilities in Mac OS X.

    Not true. There are no known vulnerabilities posted in this article. This article is nothing but hacking tools that can be used to search for vulnerabilities and to exploit certain types of vulnerabilities if/when they become known.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close