Apple patches two critical QuickTime for Java flaws
On the heels of last week's Mac OS X security update, Apple on Tuesday released another software patch that the company is recommending for all users of its latest QuickTime media software.
Security Update (QuickTime 7.1.6)
The release, available as a 1.4MB download for Macs and 1.1MB download for Windows PCs, patches two open gashes in the version of QuickTime for Java that ships with QuickTime 7.1.6.
In particular, Apple said a design issue exists in the Java software which may allow a web browser's memory to be read by a Java applet. Therefore, by enticing a user to visit a web page containing a maliciously crafted Java applet, an attacker can trigger the issue which may lead to the disclosure of sensitive information from recent browser sessions. Apple said it has addressed the issue in the security update by clearing memory before allowing it to be used by untrusted Java applets.
Meanwhile, the Mac maker said a second implementation issue discovered in QuickTime for Java may allow malicious websites to trigger arbitrary code execution. The company said the update addresses the issue by performing additional validation of Java applets.
Security Update 2007-005
The QuickTime for Java fix comes just five days after Apple released Security Update 2007-005 for both its Mac OS X Tiger (15.7MB download for PowerPC Macs, 29.2MB download for Intel Macs) and Mac OS X Panther operating systems (56MB download for Panther Server and 42.5MB download for Panther client).
For Tiger users, the security updated patched issues with bind, CarbonCore, CoreGraphics, crontabs, fetchmail, file, iChat, mDNSResponder, PPP, ruby, screen, texinfo, and VPN.
For Panther users, the update addresses issues with bind, CarbonCore, crontabs, fetchmail, file, iChat, ruby, screen, texinfo, and VPN.
Security Update (QuickTime 7.1.6)
The release, available as a 1.4MB download for Macs and 1.1MB download for Windows PCs, patches two open gashes in the version of QuickTime for Java that ships with QuickTime 7.1.6.
In particular, Apple said a design issue exists in the Java software which may allow a web browser's memory to be read by a Java applet. Therefore, by enticing a user to visit a web page containing a maliciously crafted Java applet, an attacker can trigger the issue which may lead to the disclosure of sensitive information from recent browser sessions. Apple said it has addressed the issue in the security update by clearing memory before allowing it to be used by untrusted Java applets.
Meanwhile, the Mac maker said a second implementation issue discovered in QuickTime for Java may allow malicious websites to trigger arbitrary code execution. The company said the update addresses the issue by performing additional validation of Java applets.
Security Update 2007-005
The QuickTime for Java fix comes just five days after Apple released Security Update 2007-005 for both its Mac OS X Tiger (15.7MB download for PowerPC Macs, 29.2MB download for Intel Macs) and Mac OS X Panther operating systems (56MB download for Panther Server and 42.5MB download for Panther client).
For Tiger users, the security updated patched issues with bind, CarbonCore, CoreGraphics, crontabs, fetchmail, file, iChat, mDNSResponder, PPP, ruby, screen, texinfo, and VPN.
For Panther users, the update addresses issues with bind, CarbonCore, crontabs, fetchmail, file, iChat, ruby, screen, texinfo, and VPN.
Comments
And, what's the definition of "trusted Java apps"?
Wouldn't clearing the Java session memory kind of ruin any other concurrent apps running?
I'm reasonably sure that those other apps would be running in a different session.
--yummy, inventive metaphors! ;
I'm curious if anyone has found this as a "feature" and if it will break anything.
Gmail web interface is broken after this update!
EDIT: Turns out the update was NOT the cause. Gmail was just being flaky...
Wouldn't clearing the Java session memory kind of ruin any other concurrent apps running?
The article states that this is a error with previous sessions in the browser. This won't affect any other apps running or any other browser sessions.
And, what's the definition of "trusted Java apps"?
This is referring to applets, not applications. By default, when a browser runs an applet, it runs inside a sandbox so the applet does not have access to anything on your system (printers, clipboard, the file system, etc). When developers need to have an applet access the system (say to paste some text into the applet), they can "sign" the applet. Now, when the browser runs the applet, the browser (actually, the Java plug-in for the browser) will prompt the user if the applet is from a trusted source. If so, the applet will have access to the system. Pretty simple, really... ;-)