Safari/Mac OS X Exploit, Worm, whatever..

maiklmaikl
Posted:
in General Discussion edited January 2014
On my homepage



http://www.mathematik.uni-ulm.de/num.../index_us.html



I am hosting an exploit for Safari on Mac OS X. It requires that in Safari the option has to be enabled that allows "secure files" to be lunched automatically. Many users have this option enabled.



In this case it is sufficient that if you click on a link an shell-script is executed. In my example the shell script only prints "Hallo Welt". But it also could send emails or delete the user's home directory.



There will be no warning.



In several German online sites it was reported about my exploit:



In English:

http://www.heise.de/english/newsticker/news/69862



In German:

http://www.heise.de/newsticker/meldung/69854



http://www.macnews.de/news/74203



http://www.macwelt.de/news/macosx/336525/index.html



best regards from Ulm/Germany,



Michael

Comments

  • Reply 1 of 19
    maiklmaikl Posts: 4member
    Hmm, seems the URL to my Homepage is not corret, it should be:



    http://www.mathematik.uni-ulm.de/numerik/staff/lehn/
  • Reply 2 of 19
    maiklmaikl Posts: 4member
    And the English Version is



    http://www.mathematik.uni-ulm.de/num...macosx_us.html
  • Reply 3 of 19
    andersanders Posts: 6,523member
    Send a mail to [email protected]



    If it isn´t fixed very quickly then they can´t say they weren´t told.
  • Reply 4 of 19
    vox barbaravox barbara Posts: 2,021member
    Quote:

    Originally posted by maikl

    ...

    But it also could send emails or delete the user's home directory.



    There will be no warning...[/B]



    If it is that easy to write some shell scripts, that do really bad things,

    why haven't anybody out there used this exploit, anyway.
  • Reply 5 of 19
    hirohiro Posts: 2,663member
    oops
  • Reply 6 of 19
    toweltowel Posts: 1,479member
    Quote:

    Originally posted by Vox Barbara

    If it is that easy to write some shell scripts, that do really bad things,

    why haven't anybody out there used this exploit, anyway.



    Because it sounds like Apple wrote some unbelievably stupid code. If I understand correctly, "Open safe files after downloading" will automatically open certain types of files that ought to be safe - but with three caveats that interact to create this dumbfounding flaw:

    1. Safari only looks at the file extension to determine what a "safe" file is. So any file with a ".jpg" extension will be opened, whether or not it's a jpg.

    2. To actually open the file, the Finder issues an "open" command, which will open the file in whatever application is designated by the *real* file type - not what the extension would suggest.

    3. Apple's preventative measure to keep scripts from being run by accident relies on identifying script by the leading shebang line. But a shell script doesn't *need* a shebang line if can be executed by the user's default shell.



    So they wrote an executable shell script sans shebang, appended ".jpg" to the file name, and zipped it. Safari unzips, Finder opens the "jpg" in Terminal, and bash executes it. I can't believe that it works, but it does. Probably no one's noticed this before because it relies on the coincidence of how Apple decided to implement its past security measures - 1, 2 and 3 - which are very non-obvious.



    You'd think Apple could take advantage of the executable bit to prevent this - like prevent any file with the executable bit set from being automatically opened. I don't know what the side effects would be wrt handling disk images or archives, but it would stop scripts a hell of a lot more effectively than looking for a shebang.



    Edit: For now, it seems clear that we should turn off "Open safe files" until there's a definitive fix for this. This is really kinda scary.



    Edit2: Number 2 might be specific to how the file is ZIP'd. If I ZIP the script using Stuffit or gzip, the file is opened in Preview (as you'd hope and expect).
  • Reply 7 of 19
    dutch peardutch pear Posts: 588member
    Wow, that is really stupid! No OS/browser should have an option to automatically open files without verifying whether there is executable code in it!



    Fix this NOW, apple!
  • Reply 8 of 19
    wgauvinwgauvin Posts: 100member
    It was found that the resource fork for this 'jpeg' was assigned to being Terminal.app. A flaw in Mac OSX is that if the file set to run in Terminal has a shebang (the #! line at the top) then it will prompt the user if they want to execute the file. However if there is no line, Terminal.app just runs the file as if it was a bash script and gives no warning.



    Apple could easily fix this by causing all applications to run via Terminal.app to actually require the user to be warned and allow them to cancel it. This is nagware, but even the most savvy security concious need a reminder now and then.
  • Reply 9 of 19
    vox barbaravox barbara Posts: 2,021member
    Quote:

    Originally posted by Towel



    Edit: For now, it seems clear that we should turn off "Open safe files" until there's a definitive fix for this. This is really kinda scary.



    Yes it is, i am really shocked right now. Unbelievable.
  • Reply 10 of 19
    wgauvinwgauvin Posts: 100member
    Quote:

    Originally posted by Towel

    Edit2: Number 2 might be specific to how the file is ZIP'd. If I ZIP the script using Stuffit or gzip, the file is opened in Preview (as you'd hope and expect).



    What zip program also adds the hidden resource forks (like the . files and all)? This is how the guy set it up. If from a term you did a gzip on the file, it would probably just be that file, but whatever the person did he had those hidden files which said to launch via Terminal.app not Preview.
  • Reply 11 of 19
    yoseyose Posts: 62member
    What about Apple creating a check so that whenever something is opening it will compare the metadata containing the application info and the .extension to see if they match/or are "normal" - if not it'll inform the user.
  • Reply 12 of 19
    r3dx0rr3dx0r Posts: 201member
    or just have the extension always match the metadata info.



    additionally i'd like to have the option to have terminal.app show me the contents of a script before executing it and give me the option not run it . even if i doubleclick it in the finder.
  • Reply 13 of 19
    gregmightdothatgregmightdothat Posts: 1,709member
    Unsanity has released a work-around "patch" (haxie) that solves the problem.



    http://www.unsanity.org/archives/000449.php



    You need their (free) Application Enhancer to use it.



    Quote:

    Originally posted by wgauvin

    What zip program also adds the hidden resource forks (like the . files and all)? This is how the guy set it up. If from a term you did a gzip on the file, it would probably just be that file, but whatever the person did he had those hidden files which said to launch via Terminal.app not Preview.



    Apple's does.
  • Reply 14 of 19
    mac_dollmac_doll Posts: 527member
    Has anyone emailed Steve yet?
  • Reply 15 of 19
    xoolxool Posts: 2,460member
    Quote:

    Originally posted by Towel

    Edit: For now, it seems clear that we should turn off "Open safe files" until there's a definitive fix for this. This is really kinda scary.





    Who leaves this feature on?



    Sure, its on by default and needs to be fixed, but really.



    I should offer a Free Security Product, a simple applescript that toggles that setting to off! Hmm, not a bad idea.
  • Reply 16 of 19
    vox barbaravox barbara Posts: 2,021member
    Quote:

    Originally posted by maikl

    On my homepage



    http://www.mathematik.uni-ulm.de/num.../index_us.html



    I am hosting an exploit for Safari on Mac OS X. It requires that in Safari the option has to be enabled that allows "secure files" to be lunched automatically. Many users have this option enabled.



    In this case it is sufficient that if you click on a link an shell-script is executed. In my example the shell script only prints "Hallo Welt". But it also could send emails or delete the user's home directory.



    There will be no warning.



    In several German online sites it was reported about my exploit:



    In English:

    http://www.heise.de/english/newsticker/news/69862



    In German:

    http://www.heise.de/newsticker/meldung/69854



    http://www.macnews.de/news/74203



    http://www.macwelt.de/news/macosx/336525/index.html



    best regards from Ulm/Germany,



    Michael





    Uhhh... well, i did some research on this subject, and

    i learned that this kind of exploit and many more are

    known since 2004 at least, scary ...

    Look at this PDF file, browse until you

    read "Vulnerability#6. Oh man, ...
  • Reply 17 of 19
    ipeonipeon Posts: 1,122member
    Quote:

    Originally posted by Vox Barbara

    Uhhh... well, i did some research on this subject, and

    i learned that this kind of exploit and many more are

    known since 2004 at least, scary ...

    Look at this PDF file, browse until you

    read "Vulnerability#6. Oh man, ...





    That is not good news. Almost too unreal to believe... If these are indeed true Security Concepts, Problems and Exploits in OS X that Apple has known about since 2004 and done nothing about... Like I said, something isn't right here... It better not be Apple f***king up.
  • Reply 18 of 19
    elixirelixir Posts: 782member
    i hope steve and the execs over at apple didn't think that doing some R&D for security was worth it yet.



    i'm praying they have something figured out for god sakes.
  • Reply 19 of 19
    gregmightdothatgregmightdothat Posts: 1,709member
    Quote:

    Originally posted by Vox Barbara

    Uhhh... well, i did some research on this subject, and

    i learned that this kind of exploit and many more are

    known since 2004 at least, scary ...

    Look at this PDF file, browse until you

    read "Vulnerability#6. Oh man, ...



    That's from 2004.



    No. 2 has been fixed after the Opener malware in a security update.



    No. 6 has been fixed with the "You're launching ______ for the first time."



    Because applications can have custom icons, they'll _always_ be disguisable as files. So that's really the only feasible solution. It just also needs check for Terminal scripts, too, which is the source of the current problem.
Sign In or Register to comment.