New Multi-Platform, MultiBrowser Java/JavaScript Vulnerability

This one is now public and it looks like it could be a biggie. Consider this your "heads up."



There is an issue with Sun's Java Virtual Machine (VM) in versions less than 1.4.2_06 that allows access, via JavaScript, to portions of a browser's Java plug-in that should NOT be available to untrusted applets.



In order to understand what's going on here, you need to understand a little about how Java applets work. Most people know Java as a cross-platform language for writing web based "applets" -- small programs that run within a web browser in what is known as a "sandbox" environment. This sandbox allows "applets" to perform a specific set of actions that are deemed "safe", and keeps it from being able to do Evil things to your machine (installing viruses, formatting your hard drive, transferring money from your bank account into the ISC Handler's slush fund, etc...)



In order for Java applets to do their thing, however, the "plug-in" (the part of the browser that actually runs the applets) has to have some capabilities that you would never trust to an applet. All that stands in the way are the rules that limit what an "applet" is allowed to do within the plug-in itself. It is these rules that constitute the Java "sandbox."



Think of the movie "Silence of the Lambs." If you haven't seen it, this won't make sense, so go out right now, rent it, watch it, and come back. No, I'm not kidding. Tell your boss I said it's "security research." Ready? Ok. You can think of Java "applets" like Dr. Lechter, being downloaded into your browser on a two-wheeler, wrapped up in a straight-jacket and that muzzle/mask thingie.



Well, we all know how well that worked out, now don't we? Somewhere in the whole "wrap him up tightly enough and we'll be safe from Dr. L." mentality there was a design flaw.



Aiding and abetting the good Doctor's escape in this instance is our old friend JavaScript, which is sort of like Java's really ugly distant cousin (the one that everyone avoids at the family reunion). It turns out that JavaScript can access those parts of the Java plug-in outside of the sandbox and can pass that access along to a Java applet. This is that "design flaw" that I spoke of earlier coming home to roost. In spades.



So now we need to worry about malicious Java "applets" (with a little help from JavaScript) jumping beyond the sandbox and running around saying things like "quid pro quo" and serving up our PCs with a generous helping of fava beans.



What to do? Patch!



To see what version of the Java Plug-in is used by your browser, here are some tips courtesy of the ever helpful George Bakos:



IE: Start->Settings->Control Panel, click the Java "cup" icon labeled
"Java Plug-in" and read the version.



Opera: According to



http://www.opera.com/support/search/supsearch.dml?index=278



pulling down Opera's "Tools" menu, selecting "Advanced", then choosing
"Plug-ins" will load a window showing which plug-ins Opera has
installed.



Mozilla-based browsers (Mozilla/Netscape/FireFox): Type "about:plugins" (without the quotes) into the URL bar and smack the Enter key.



Konqueror: There is a separate KDE Java Applet Server that doesn't use the Java
plugin.



You want to make sure that you're running a plug-in that is version 1.4.2_06 or greater. Updated versions are available here:



http://java.sun.com/j2se/1.4.2/download.html



FYI, what you're looking for when you get there is the link to the "JRE", or Java Runtime Environment, right smack in the middle of the page. We've received reports that running around on Sun's site and clicking other links that you might think would get you to the right place... well... don't. (Thanks, Charles!)



If you're still in Java 1.3 Plug-in Land and not interested or able to move on to v1.4, try here (thanks, Brian!):



http://sunsolve.sun.com/search/document.do?assetkey=1-26-57591-1



According to Sun, the problem is fixed for version 1.3 in JRE 1.3.1_13 and greater.



More information on this vulnerability is available here:



http://jouko.iki.fi/adv/javaplugin.html

http://secunia.com/advisories/13271/





Yo! Microsoft!

This past weekend saw yet another round of attacks aimed at unpatched vulnerabilities in Microsoft's Internet Explorer. The so-called "Bofra" incident targets an unpatched issue with IE's handling of malicious IFRAMEs. While users of Windows XP with Service Pack #2 applied are immune (and, to answer Marc's question from yesterday's diary, this immunity appears to be a result of a change in the actual code underlying IE, not simply a matter of changes to the default security settings...) those who are not running XP and those who are unable or unwilling to apply SP2 have been left unprotected.



There is a saying: Nature abhors a vacuum. If that's true, inaction on the part of the folks in Redmond must really have Nature's undies in a bunch. Understandably enough, several independent developers have stepped into this Microsoftian-void and are now selling "unofficial" patches on the 'net for unaddressed vulnerabilities in IE, including fixes for the very IFRAME vulnerability exploited by Bofra.



Yo! Microsoft! What don't you get? People are so scared to surf with an unpatched IE that they're shelling out cold, hard cash to third-parties for a level of "Trustworthy Computing" that you should be providing. It's time to step up to the plate. Do you hear? Hello?



End users: While we can understand your frustration, we cannot recommend that you use these "unofficial," third-party patches. Applying these patches will almost certainly cause Microsoft to refuse responsibility for support going forward and using these patches could cause issues with updating your system when "official" patches finally become available.



If you find yourself in a situation where you're unable or unwilling to upgrade your system to XPSP2, there is one third-party security patch to IE that we can wholeheartedly recommend: it's called FireFox (or Netscape, or Opera, or...).



Yo! Microsoft! Did you hear that?




Open Letter To Anti-Virus Software Companies - A Response



On November 5, 2004, Chris Mosby, SMS Administrator and MyITforum Security Message Board Moderator, sent us an "Open Letter To Anti-Virus Software Companies" that we thought was interesting enough to publish:



http://isc.sans.org/diary.php?date=2004-11-05



Our favorite CTO, Johannes Ullrich, stepped into the fray in the November 8th diary:



http://isc.sans.org/diary.php?date=2004-11-08



Yesterday, we received the following response from members of the USCERT's CME (Common Malware Enumeration) initiative. While we don't have any policy about providing "equal time", we thought that their response was also interesting enough to publish:



------------------begin letter------------------



As members of US-CERT?s Common Malware Enumeration (CME) initiative, we would like to respond to Mr. Chris Mosby?s ?Open Letter to the Anti-Virus Software Companies? and let Mr. Mosby and the rest of your readers know that we recognize that there are challenges surrounding the ?Virus Name Game.? US-CERT and leading security vendors are working together to solve these challenges.



As you may be aware, US-CERT sponsors the Common Vulnerabilities and Exposures list (CVE), which has addressed similar challenges in the vulnerability space (http://www.us-cert.gov/cve/). By building upon the success of CVE and applying the lessons learned, US-CERT, along with industry participants mentioned below, hopes to address many of the challenges that the anti-malware community currently faces with respect to identifying malware through the CME initiative.



As a ?neutral third party? in the marketplace, US-CERT will coordinate with security vendors to implement a CME malware identification scheme. Limited operational capability is expected 1Q05; this phase will concentrate on the most important threats, including the recent Beagle/Bagle variants. The role of US-CERT will be to assign a CME identifier (e.g., CME-1234567) to each new, unique threat and to include additional incident response information when available. As our experience with CVE shows, once all parties adopt a neutral, shared identification method, effective information sharing can happen faster and with more accuracy, making it easier to distinguish between very similar threats. In this manner, US-CERT believes that an effective structure can be built to improve what is currently the chaotic world of malware identification.



As mentioned both in Mr. Mosby?s letter and the response posted on November 8th, there are significant obstacles to effective malware enumeration, including the large volume of malware and the fact that deconfliction can be difficult and time-consuming. The CVE experience confirms that strong industry support and involvement is required to meet these challenges. To this end, US-CERT is working with some of the key industry players, including McAfee, Symantec, TrendMicro, and Microsoft. In addition, US-CERT plans to meet with other stakeholders to explore how they can contribute and participate. To date, all parties have shown a strong willingness to work together toward the goal of improving the malware information resources available to AV software users, first responders, and malware analysts ? anyone who depends on accurate, concise information about malware. Solving the virus naming problem is a challenging process, but a goal shared across the industry.



We certainly welcome observations such as Mr. Mosby?s. From our point of view, the question is not ?why should we have CME IDs? but ?how do we make CME IDs work??



Desiree Beck, CME Technical Leader

US-CERT



Andy Purdy, Acting Director NCSD

Department of Homeland Security



Larry Hale, Deputy Director NCSD

Department of Homeland Security



Jimmy Kuo

McAfee Fellow - McAfee, Inc.



Matthew Braverman, Program Manager

Microsoft Corporation

Security Business and Technology Unit ? Antivirus Team



Mady Marinescu, Development Lead

Microsoft Corporation

Security Business and Technology Unit ? Antivirus Team



Randy Treit, Program Manager

Microsoft Corporation

Security Business and Technology Unit - Antivirus Team



Vincent Weafer, Senior Director, Symantec Security Response

Symantec Corporation



Oscar Chang, Executive Vice President

Trend Micro, Incorporated



Joe Hartmann, Director North American

Anti-virus Research Group

Trend Micro, Incorporated



-------------------end letter-------------------





No Bounce

Ain't no "Bouncing Malware" here... Ain't no room. It's pretty much complete, but needs a little polishing. Perhaps if Pedro isn't too wordy today, I'll see if I can "borrow" some space from him.





-----------------------------------------------------------

Handler On Duty: Tom Liston ( http://www.labreatechnologies.com )