Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apple Responds to MOAB

Posted by CmdrTaco on from the that-was-pretty-fast dept.

frdmfghtr writes "Apple has released what appears to be the first security update as a result of the "Month of Apple Bugs." While the Apple site doesn't explicitly say that the fix was a result of the MOAB, it does point to a sample Quicktime file that triggers the overflow flaw (well, sort of...it says the file is there but doesn't provide any links)."

4 of 126 comments (clear)

  1. ummm by Kyro · · Score: 5, Informative

    from the linked apple release: " A QTL file that triggers this issue has been published on the Month of Apple Bugs web site (MOAB-01-01-2007). This update addresses the issue by performing additional validation of RTSP URLs."

    is that not explicit enough??

    --
    save the GNUs!
    1. Re:ummm by 99BottlesOfBeerInMyF · · Score: 4, Informative

      I expected to see an acknowledgment along the lines of "Thanks to the MOAB team for alerting Apple of this flaw in Quicktime." For all we know, Apple already knew about it and fixed it without any help from the MOAB effort. Even Microsoft acknowledges outside efforts that uncover flaws in Microsoft products.

      Apple acknowledges contributions from users who report bugs to them. Just read any of their security patches and about half the items are attributed to a bug reporter outside the company. The question is, did the MOAB really report this bug to Apple as they strongly implied? We know they did not report the bug to the OmniGroup team, since their CEO went on record saying they found out about it from someone who say the MOAB site.

      If I were Apple I wouldn't give these guys credit at all, seeing as they are behaving unethically and irresponsibly. Giving them press just encourages others to behave like this.

  2. Re:Response by 99BottlesOfBeerInMyF · · Score: 5, Informative

    I was more troubled by the way they treated Omniweb...

    Even more troubling is the hubbub surrounding their Colloquy vulnerability, mentioned in this article. They are accused of actually using the exploit on a public IRC channel before releasing the vulnerability and publishing a log of that hack in the announcement. I don't know if it is true, but given their behavior with the rest of this project they're slipping more and more towards the blackhat end of the spectrum.

  3. Lots of comment... by shawnce · · Score: 5, Informative

    I am see several comments from folks stating that they are surprise that Apple is taking steps to patch issues ("taking it seriously", etc.). I find that a little strange comment given that Apple is actually rather good about addressing vulnerabilities that others report to them and give them credit (if they reported it to Apple). Granted Apple's general no comment policy until investigated and patched can be a little annoying if you report an issue and would like to know more but that policy doesn't mean that Apple doesn't take security reports seriously.

    Just review all of the attribution Apple has given for the many vulnerabilities they have addressed over the years. For example look at the security release announcements for 2006 (mailing list archive).

    As a side note a few MOAB issues are centered on group admin writable locations that can be used to take over the system is you have local access (possibly via a remote exploit). It may take Apple a little while to address this type of issue given the possibility of permission changes causing Apple and 3rd party software (installers most likely) to fail for customers. Luckily a few new security related feature will debut in Mac OS X 10.5 that will make this type of attack harder to pull off (us 3rd party developers should adopt them ASAP).

    A brief listing...

    CoreGraphics
    CVE-ID: CVE-2006-1444
    Available for: Mac OS X v10.4.6, Mac OS X Server v10.4.6
    Impact: Characters entered into a secure text field can be read
    by other applications in the same window session
    Description: Quartz Event Services provides applications with
    the ability to observe and alter low-level user input events.
    Normally, applications cannot intercept events when secure event
    input is enabled. However, if "Enable access for assistive
    devices" is on, Quartz Event Services can be used to intercept
    events even when secure event input is enabled. This update
    addresses the issue by filtering events when secure event input
    is enabled. This issue does not affect systems prior to Mac OS X
    v10.4. Credit to Damien Bobillot for reporting this issue

    Keychain
    CVE-ID: CVE-2006-1446
    Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS
    X v10.4.6, Mac OS X Server v10.4.6
    Impact: An application may be able to use Keychain items when
    the Keychain is locked
    Description: When a Keychain is locked, it is not possible for
    applications to access the Keychain items it contains without
    first requesting that the Keychain be unlocked. However, an
    application that has obtained a reference to a Keychain item
    prior to the Keychain being locked may, in certain
    circumstances, be able to continue using that Keychain item
    regardless of whether the Keychain is locked or unlocked. This
    update addresses the issue by rejecting requests to use Keychain
    items when the Keychain is locked. Credit to Tobias Hahn of HU
    Berlin for reporting this issue    .

    GDB
    CVE-ID: CVE-2006-4146
    Available for: Mac OS X v10.4 and later
    Impact: Opening a maliciously-crafted DWARF binary with GDB may
    lead to arbitrary code execution
    Description: GDB, the GNU Debugger, is susceptible to multiple
    vulnerabilities that may lead to arbitrary code execution when
    loading maliciously-crafted DWARF binaries. This update
    addresses the issues by performing additional validation while
    handling DWARF binaries. Credit to Will Drewry and Tavis Ormandy
    of the Google Security Team for reporting this issue    .

    etc.