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

 



Forgot your password?
typodupeerror
×
Apple Businesses

Month of Apple Bugs - First Bug Unveiled 240

ens0niq writes "The first bug (a Quicktime rtsp URL Handler Stack-based Buffer Overflow) of the Month of Apple Bugs has been unveiled — as previously promised — by LMH and Kevin Finisterre. From the FAQ: 'This initiative aims to serve as an effort to improve Mac OS X, uncovering and finding security flaws in different Apple software and third-party applications designed for this operating system. A positive side-effect, probably, will be a more concerned (security-wise) user-base and better practices from the management side of Apple.'"
This discussion has been archived. No new comments can be posted.

Month of Apple Bugs - First Bug Unveiled

Comments Filter:
  • removed, but... (Score:3, Informative)

    by ens0niq ( 883308 ) on Tuesday January 02, 2007 @08:59AM (#17431036)
    Credit line removed by the editor, but i found this report on HUP [hup.hu].
  • No problem! (Score:4, Funny)

    by fo0bar ( 261207 ) on Tuesday January 02, 2007 @09:02AM (#17431054)
    This isn't a problem because it has been proven that only Windows can get viruses. Therefore, because it's not possible for viruses to spread with MacOS, security threats are irrelevant.

    Please, try the veal.
    • by elrous0 ( 869638 ) *
      Normally I wear protection, but then I thought, "When am I gonna make it back to Haiti?"

      Bad Idea Jeans [jt.org]

      -Eric

    • Re: (Score:2, Insightful)

      In all seriousness, no reasonable person thinks that "only" Windows can get viruses.

      One comment I have had (which I doubt will be approved as a comment on the blog, since - other than technical posts - lmh only seems to accept congratulatory comments), and which I am curious to have feedback on is this, below, which was in response to lmh saying:

      It's a matter of time to see this getting abused in the wild. Hopefully, due to exploits being released for every critical issue, the usual 'not a problem' claims w
  • Is this true? (Score:4, Insightful)

    by bogie ( 31020 ) on Tuesday January 02, 2007 @09:11AM (#17431112) Journal
    "The problem with so-called 'responsible disclosure' is that for some people, it means keeping others on hold for insane amounts of time, even when the fix should be trivial."

    Is Apple as bad as MS when it comes to fixing security flaws? Is there really a need to show how "insecure" OS X is? Or is this more a "your going to start listening to security experts when they have something to say or else..." type situation. I did read the FAQ but they really don't show any evidence to prove why this is a good thing, how this will improve OS X security, or how Apple has been unwilling to fix flaws in the past.

    They could be 1000% right, but on the surface I just don't see anything which either confirms or denies their theory. It would be nice to at least read some sort of history of how Apple has interacted with Security researchers in the past.
    • "The problem with so-called 'responsible disclosure' is that for some people, it means keeping others on hold for insane amounts of time, even when the fix should be trivial."

      They could have thought of a better excuse than this. Giving the vendor n days before disclosure avoids the 'insane amounts of time' scenario, so the argument doesn't hold water. Conscientious greyhats go this route. Maybe we'll call these guys charcoal-greyhats.

      So we're left to conclude that they just want attention/fame/notoriety
    • Is Apple as bad as MS when it comes to fixing security flaws?

      Actually, Apple are much slower than Microsoft at fixing bugs. It's hard to compare like with like, perhaps the least indirect way to see Apple's slow response is to compare the speed with which Linux and BSD distros package and release fixes, and the official Apple releases for the same bugs. Microsoft have on occasion turned a bug round within their calendar-month release cycle (ie released a patch for a bug on the very next patch Tuesday.) Arguably this is because Microsoft have had a lot more practice

  • Doesn't work for me (Score:5, Interesting)

    by Anonymous Coward on Tuesday January 02, 2007 @09:12AM (#17431120)
    I just tried this on my MacBook Pro using the provided QTL files and ruby scripts, but none of them seem to have the claimed effect. Anybody else already tried this?
    • by Sentry21 ( 8183 )
      Didn't entirely work for me either. I wonder if this is just a bug in their exploit code? Either way, I'm on a Macbook, so I wonder if this is Intel-specific.

      dan@Reykjavik:~/Desktop$ ruby MOAB-01-01-2007.rb
      MOAB-01-01-2007.rb:58:in `close': closed stream (IOError)
      from MOAB-01-01-2007.rb:58:in `open'
      from MOAB-01-01-2007.rb:58
      dan@Reykjavik:~/Desktop$ /Applications/QuickTime\ Player.app/Contents/MacOS/QuickTime\ Player pwnage.qtl
      sh: -c: line 1: unexpect

    • Didn't work for me either. Tries it on my G4 Powerbook with no results whatsoever.

    • I just tried this on my MacBook Pro using the provided QTL files and ruby scripts, but none of them seem to have the claimed effect. Anybody else already tried this?

      I could not. And only one person I know could. Other people had to heavily modify the script and run QT Player in gdb along with some other voodoo to get it to exploit properly. Doesn't seem like this will cause much harm.

      Either way, a third party developer already fixed this [unsanity.org] crasher.
  • OS X is unimaginably complex. Even the 1500+ page "OS X internals" tome just scratches the surface of most things.

    (Note that I own and enjoy using a MacBook, so I'm not blindly Apple-bashing.)

    The complexity is the first problem. The second is that almost all of the code was written in an insecure manner. No one was doing code-level security reviews on QuickTime and Quartz and all the other bits of OS X. And even if you did, squashing all potential overflow/overwrite bugs in a language like C is essentia
    • Re: (Score:2, Interesting)

      by Jeff DeMaagd ( 2015 )
      It's not just C though, Apple generally uses Objective-C, which is an object-oriented extention of C. If the programmers did the responsible thing and called libraries for their objects, then it shouldn't be a problem, fix your libraries. They shouldn't be calling for memory using C if they can avoid it. I don't think it's anywhere nearly so simple though.
      • by bnenning ( 58349 )
        Apple generally uses Objective-C

        They use ObjC for lots of apps, but the OS-level code that these sorts of exploits target is almost all C/C++. GP is correct, we really need to stop using C and other unsafe languages except in situations where it's absolutely required for performance or low-level access.
    • Not to minimise the problems of writing large complex software systems, but complexity is the second problem... insecure design is the first.

      I'm more concerned with the fact that Safari uses the same URI handler and helper database as Finder (LaunchServices) and that Apple is more interested in giving people a false sense of security with pop-up dialogs than changing the API slightly to make it inherently secure.

      * Split LaunchServices up into "web oriented" applications that are indended for use with untrus
    • This is a very good point. Also, if you can have this kind of problem in Apple's software, wouldn't the same thing (buffer overflow) be possibly with any third party app that uses a stack based buffer?

      I'm certainly not trying to say MacOS X is perfect or that Microsoft has it any easier. This is a larger problem than just Apple vs. Microsoft. Unfortunately, the only solution I've seen proposed is Trusted Computing which sounds to me like a solution that is worse than the problem it solves.
  • by Llywelyn ( 531070 ) on Tuesday January 02, 2007 @09:31AM (#17431264) Homepage
    If they were truly interested in "improving MacOS X" or "improving practices on the management side of Apple" then they would release these bugs to Apple first. Don't wait an insane amount of time, but give them a nice reasonable amount of time to fix the bugs. Heck, even tell them you plan on releasing them on thus and so date and start the month *then*, giving props to Apple for those they have fixed.
  • Doesn't work (Score:3, Informative)

    by matth ( 22742 ) on Tuesday January 02, 2007 @09:46AM (#17431428) Homepage
    I tried the exploit.. doesn't work on my macbook.
    • Re: (Score:2, Interesting)

      by owsla ( 78381 )
      Same thing here on a 3rd generation PowerBook G4 with all available updates. I tried to the ruby script -- it just crashed Quicktime, but no exploit.
      • The *demo* crashes by simply trying to jump to the address "0xbabeface". The point is that if they wanted to, they could have used a more dangerous payload, like a virus.

        Heh. If they had released a demo that actually did something nasty, now *that* would have been irresponsible.
    • Doesn't work on my iMac G5 running 10.4.8 with Quicktime 7.1.3.

      Maybe it only affects PC users with Quicktime, or maybe you have to have Quicktime Pro installed?

      Don't give them the publicity. Certainly Apple's software team should read the site, but they don't deserve any more attention than that; Their whole site is dedicated to insulting Apple and taking pot-shots. They write like capricious seven-year-olds. I, for one, am going to ignore them for the rest of the month -- and probably for the rest o

    • Fails on my iMac G5 rev. 1, OS X 10.4.8 too. Looks like this particular "bug" has more FUD than substance.
  • Timing (Score:3, Interesting)

    by lord_iain ( 1045936 ) on Tuesday January 02, 2007 @10:05AM (#17431568)
    Is it just me, or is this event well timed? A month of Apple bugs/exploits on the lead up to Windows Vista's commercial release on January 30th (the most "secure" version of Windows). Sounds sinister to me.
  • OK (Score:2, Funny)

    by WiseMuse ( 1039922 )
    Q: What's worse than finding a worm in your apple? A: Finding a bug in your MAC.
  • I can help but feel that this whole thing is just sour grapes. I certainly don't feel that improving OSX is the sole motivation behind this. The blog reeks of immaturity and lacks any form of professionalism. The language is smug and juvenile? pwnage? (Wow, high school all over again). They go into great deatil on how execute the exploit but dedicate one sentence on how to avoid it. Then, where is the discrete vendor warning that traditional researchers give before going public? They are not doing it! Are

    • The problem is from what happened last year during the "month of kernel bugs" - that website was dedicated to exposing problems in all popular operating systems - which was all well and good and interesting and useful - but when they published Apple bugs they apparently collected a lot of hate from Apple users.

      Apparently they collected enough hate from various Apple blogs and users that it motivated them to create this second site.
  • While I've played with ruby, perl, C and work almost daily in a variety of shells I honestly don't have the background to fully understand what they've offered up here.

    From the article (and based on my limited understanding) it relies on the shell and curl being resident in a known memory location? Can someone with deeper OS X internals knowledge explain why the system would always put the shell and curl into the same memory space? This seems to go contrary to what I would expect; that the system alloca

    • I just recently learned more about this;

      Yes, you can assume that when a given application loads into memory the various components will end up in the same addresses every time.

      Think about it - in a virtual memory system, memory addresses are rewritten so that the application thinks it has all of memory to itself, even though it doesn't. So, even if the physical location the application gets loaded to is probably different every time, the virtual addresses are almost always going to be the same.

      So, how do yo
      • So, how do you defend against this? Apparently, newer operating systems, including Vista and XP (I think?) have a randomizing function that changes the virtual addresses around so that they are different every time the program is loaded. This helps make this kind of exploit harder - although I suspect there are still ways to do it.

        Randomization works by making it harder to guess the correct address -- 99.9% of the time you'll just crash the program and that's the end of your exploit attempts. But how st

        • Although I've never seen any hard numbers on how much pre-binding improves things; as a developer it has given my serious problems because it complicates how shared libraries are built.
    • From the article (and based on my limited understanding) it relies on the shell and curl being resident in a known memory location? Can someone with deeper OS X internals knowledge explain why the system would always put the shell and curl into the same memory space? This seems to go contrary to what I would expect; that the system allocates memory when a program is executed and that memory can be any from the available pool.

      It's called "virtual memory." Where the program and its data physically ARE in

    • Re: (Score:3, Informative)

      by iluvcapra ( 782887 )

      It's not calling curl or the shell from memory, it appears (from the description) to be a return-to-libc-attack. I am not an expert on this particular thing, but a return-to-libc attack is where you use a buffer overflow to overwrite the return address of the stack frame. Under normal circumstances, the rtsp URL parser would return to his calling function, but if an overflow overwrites the return address, you can basically rewrite the stack's memory of who called the URL parser in the first place. So, in

  • A positive side-effect, probably, will be a more concerned (security-wise) user-base and better practices from the management side of Apple.'"
    Yehp, incluiding folks like my Dad, who will avoid apples since they have known security issues anyway, and MS is the standard. So.. he'll make sure the fortune 500 company he acts as CTO for remains on Microsoft.

    We just had this argument last night.. great to see so much "support" from the alternative OS community.

    -GiH
  • by Paradox ( 13555 ) on Tuesday January 02, 2007 @01:26PM (#17433670) Homepage Journal
    The assumed known address is wrong, but it does crash quicktime on my machine.

    Snips from my crash log:

    OS Version: 10.4.8 (Build 8N1051)
    Report Version: 4

    Command: QuickTime Player
    Path: /Applications/QuickTime Player.app/Contents/MacOS/QuickTime Player
    Parent: WindowServer [57]

    Version: 7.1.3 (7.1.3)
    Build Version: 65
    Project Name: QuickTime
    Source Version: 4650000

    PID: 9548
    Thread: Unknown

    Exception: EXC_BAD_INSTRUCTION (0x0002)
    Code[0]: 0x00000001
    Code[1]: 0x00000000 ...

    Unknown thread crashed with X86 Thread State (32-bit):
        eax: 0xffffffff ebx: 0x41414141 ecx: 0x900012f8 edx: 0xffffffff
        edi: 0x41414141 esi: 0x41414141 ebp: 0xdeadbabe esp: 0xbfffd628 (hello deadbabe!)
          ss: 0x0000001f efl: 0x00010286 eip: 0x918bef3a cs: 0x00000017
          ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

    Not so good. :)
  • Apple routinely patches much more serious bugs at the OS level so I don't understand what all the fuss is about. The fact remains that the security situation in Windows was so ludicrous that an unpatched Windows machine would be compromised within minutes of being connected to the internet. It forced Microsoft to drop everything and perform a security sweep of all their existing software, causing the highly visible delays in products such as Vista and Visual Studio 2005. And the security procedures in pl
    • by Kevinv ( 21462 )
      If the goal is to create a zombie machine used to send spam then this exploit is perfectly valid, OS X will allow a user level account to send e-mail without further modifications to the OS. If the goal is dump all a user's files looking for a document that might be chock full of social security numbers or back accounts (as several recently stolen laptops have been) this is also a valid exploit.

      Why do only OS level exploits count?

    • This isn't a pissing contest; pointing to the insecurity of Windows doesn't make OS X secure - the point is that Apple can and should do more to secure OS X.

      This is actually an opportunity for Apple to win some hearts and minds - both from the security community and from users at large. If they go after these holes and patch them aggressively then their reputation can only be improved. If, instead, this month simply becomes "the month of fanboys attacking security researchers" you can expect Apple to lose s

"Everyone's head is a cheap movie show." -- Jeff G. Bone

Working...