Apple bolsters security in QuickTime 7.3

“Less than a week after its QuickTime media player made the top-ten list of most vulnerable Windows applications, Apple shipped QuickTime 7.3 to patch… at least seven vulnerabilities that could lead to code execution attacks,” Ryan Naraine blogs for ZDNet.

“The update, available for both Mac and Windows (XP and Vista) users, also includes the removal of QuickTime for Java [QuickTime for Java no longer accessible to untrusted Java applets], a move that significantly reduces the attack surface on the company’s flagship digital media player,” Naraine reports.

Naraine details the seven fixes Apple has provided in QT 7.3 in the full article here.

15 Comments

  1. Apple didn’t *nuke* QuickTime for Java, it simply locked it down to only being accessible by TRUSTED Java apps. Big difference.

    —-
    CVE-ID: CVE-2007-3751

    Available for: Mac OS X v10.3.9, Mac OS X v10.4.9 or later, Mac OS X v10.5, Windows Vista, XP SP2

    Impact: Untrusted Java applets may obtain elevated privileges

    Description: Multiple vulnerabilities exist in QuickTime for Java, which may allow untrusted Java applets to obtain elevated privileges. By enticing a user to visit a web page containing a maliciously crafted Java applet, an attacker may cause the disclosure of sensitive information and arbitrary code execution with elevated privileges. This update addresses the issues by making QuickTime for Java no longer accessible to untrusted Java applets. Credit to Adam Gowdiak for reporting this issue.
    —-

  2. LOL at some of you saying “no Java” … it said “untrusted Java applets”, i.e. “trusted Java applets” are still fine ” width=”19″ height=”19″ alt=”smile” style=”border:0;” /> (as coolfactor also points out).

    Not long until iPhone Friday here in UK!

  3. “Old, Lame and all that. AJAX, now that is where the future lies.”

    I can’t tell if you’re being sarcastic or not. In order for AJAX to fully supplant Java, for one thing it would have to get rid of it’s browser dependence and become more platform independent; AJAX’s reliance on JS means it can work differently with different browsers, which makes for a lot more testing & compatibility problems than if you just do it in Java.

  4. This seems to be a huge issue for few people.

    Not to down play your findings… but I imagine for the average user and even for several mid size ad agencies/studios that an all Mac environment has not seen these issues.

    In my office we use a 4 Octain and 2 SGI Orgin servers which are transfering MASSIVE amounts of data / files every minute. All without any issue or loss of data what-so-ever. So, in the case you are describing – could you please mention what is the likely hood of this happening to the average user. Since, the average user is most-likely NOT using Windows or Samba on FreeBSD/Linux.

    Plus, WHO exactly is this person who has informed you that the bug goes back to Panther?

    I expect that you REFRESHED the folder to see if more items where in fact copied over with accordance to your test.

    This can be checked by CLOSING the folder then re-opening it.
    Then see if all the files during the copy procedure were done.
    Rather then just looking at the intial DRAG DROP tranfer before you forced the ERROR. PANTHER, definately has REFRESHing issues with file tranfers.

    So try that… close the window directory off completely. Right down to the root folder then verify again if the FILES are intact.

    By the way 20 Gbs woould be massive… 384 Mbs is a small photoshop file in my companies perspective.

    AND YES, we refresh, root down the folders after file transfer daily. However, since 10.4.10 there seemed t be an improvement with this issue.

    thx for your input and sorry if I am not so technical or misinterpreted your finding.

    Jay

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.