20
Feb 13

Critical Security Updates for Adobe Reader, Java

facebooktwittergoogle_plusredditpinterestlinkedinmail

Adobe and Oracle each released updates to fix critical security holes in their software. Adobe’s patch plugs two zero-day holes that hackers have been using to break into computers via Adobe Reader and Acrobat. Separately, Oracle issued updates to correct at least five security issues with Java.

javaiconThe Java update comes amid revelations by Apple, Facebook and Twitter that employees at these organizations were hacked using exploits that attacked Java vulnerabilities on Mac and Windows machines. According to Bloomberg News, at least 40 companies were targeted in malware attacks linked to an Eastern European gang of hackers that has been trying to steal corporate secrets.

Oracle’s update brings Java on Windows systems to Java SE 7 Update 15, and Java 6 Update 41. Most consumers can get by without Java installed, or least not plugged into the browser. Because of the prevalence of threats targeting Java installations, I’d urge these users to remove Java or unplug it from the browser. If this is too much trouble, consider adopting a dual-browser approach, keeping Java unplugged from your main browser, and plugged in to a secondary browser that you only use to visit sites that require the plugin. To find out if you have Java installed, visit java.com and click the “Do I have Java?” link below the big red button. Existing users can update Java from the Java Control Panel, clicking the Update tab and then the “Update Now” button.

Apple has issued an update that brings Java up-to-date on security patches but also disables the Java plugin from Web browsers on the system. Apple also issued a malware removal tool that it said should remove from Macs the most common variants of malware that used the most recent Java exploits.

Adobe’s update brings Reader XI to version 11.0.2 and Reader X to v. 10.1.6 on both Mac and windows (see the graphic below for other versions). This patch fixes a couple of critical flaws that Adobe said last week hackers were exploiting to break into vulnerable systems.

adobe2-20-13

Finally, Firefox users may be happy to know that the newest version of the browser now includes its own PDF viewer. According to TheNextweb.com, Firefox 19 “includes PDF.js, a JavaScript library intended to convert PDF files into HTML5, which was started by Andreas Gal and Chris Jones as a research project that eventually picked up steam within Mozilla Labs. Technically, the tool has been in Firefox for many versions, but you had to manually enable it. The whole point of the built-in PDF viewer is to avoid having to use plugins with proprietary closed source code “that could potentially expose users to security vulnerabilities,” according to Mozilla. It also cuts down on extra bloat that Firefox can already do: PDF viewing plugins have their own code for drawing images and text.”

Tags: , , , , , , , , , , , , , ,

26 comments

  1. Is it now recommended that Firefox users disable either the built-in reader or whatever plug-in they had been using? I use FoxIt Reader.

    I am also disappointed to see in my plug-ins list that I have both 11.5 r502 and 11.6 r602 of Shockwave Flash. Guess their updater doesn’t get rid of old versions effectively.

    • I’d disable the old plugin (foxit, Adobe Reader etc) otherwise it may be overriding Firefox’s built-in reader.

      As far as the built in reader, I think it’s going to be a lot less targeted/exploited than other readers for a while, but I wouldn’t say it’s entirely immune (what is?).

  2. Hi,

    I was browsing through your site (krebsonsecurity.com) and found very interesting contents on money and finance which are pretty informative. I was hoping I could write a guest post on your blog with an article related to your blog, I believe this will be of interest to your readers.

    The article will be entirely unique, written just for your blog and will not be posted elsewhere. I hope I can produce informative and viscid content for you. If you’re interested in this idea, please get back to me.

    Thank you so much for your time and consideration.

    Regards,
    Jacks Edison

  3. Can’t wait for the first exploit that cracks Firefox’s JavaScript PDF reader to distribute malware or take over a machine… :-)

    At least Adobe has EXPERIENCE at doing this…however poorly they’ve learned from it. :-)

    Vee: “I think it’s going to be a lot less targeted/exploited than other readers for a while”

    About 24 hours would be my guess… :-)

    • “This PDF viewer component could be more secure than third-party plug-ins if it is written entirely in JavaScript/HTML5, Thomas Kristensen, the chief security officer at vulnerability intelligence vendor Secunia”

      http://www.pcworld.com/article/2025153/firefoxs-pdf-viewer-may-boost-security-by-boring-hackers.html

      Nothing is perfect for viewing pdf, comes with the territory of it being a universal office doc with a lot of functionality. Adobe Reader has a pretty good sandbox and is regularly patched, but it still gets hit. Even using alternative readers like Foxit have been criminally exploited by criminals.

      • “Nothing is perfect for viewing pdf”

        Well *I* just print them on paper and read the hard copy, that ought to be pretty safe.

        (just kidding! ;) )

        Personally, I’m now using the Windows 8 built-in PDF reader since it (1) has relatively limited capabilities to exploit, and (2) runs in a Win8 AppContainer so an exploit would be up against very serious constraints.

        On other versions of Windows, I’d stick with the latest release of Adobe Reader 11 and tweak it for optimal security, rather than discarding one of the only sandboxed PDF readers because it would be “too hard” to spend 60 seconds configuring its security options. In a battle, which would you rather be driving: a Humvee painted in camouflage, or a battle tank painted bright orange? “Oh no, but bullets can enter the hatch on top of the tank if it’s open!” Well then maybe consider CLOSING THE HATCH. Just sayin’ ;)

        On the topic of FireFox’s PDF reader: last I checked, FireFox as a browser still has no sandboxing or Low integrity mode (someone point out the documentation if I’m wrong, that would be great news). So a successful exploit is probably going to gain the user’s level of access to the file system, the network, and other running processes. I’m sure they’ve tried to do a good job with their PDF reader’s security, but what’s Plan B, what are the mitigations to contain an as-yet-unknown vulnerability?

        • Rabid Howler Monkey

          Mozilla collaborated with Adobe to sandbox the Flash Player plug-in in Firefox on Windows. In addition, Mozilla has recently implemented the HTML5 sandbox for iFrames (frequently used in attacks):

          http://www.infoq.com/news/2010/01/HTML-5-Sandbox-IFrame

          [Google has implemented the HTML5 iFrame sandbox since Chrome version 4. Opera has as well since Presto version 2.5. Microsoft, I believe, has included this feature in Internet Explorer 10.]

          That’s it for Firefox as far as I know.

          P.S. Proper use of the Firefox NoScript add-on to whitelist one’s frequently-visited web sites provides significant security. Hopefully, and back on topic, NoScript will allow one to whitelist sites for pdf viewing. While both Chrome and Opera support easy whitelisting, IE does only on Windows server OSs via Enhanced Security Configuration.

          • To clarify, when I mention sandboxing and/or using Low Integrity level, I’m talking about the browser’s processes as they run in Windows, whereas your article discusses restricting what HTML code is allowed to do. Both great topics… regarding my topic, if the browser (or any software) is exploited, what mitigations are in place to contain the damage? Making use of Windows integrity levels, sandboxing the browser to restrict its access to the file system, network and other processes… this is what I hope to see them work on next.

            • Rabid Howler Monkey

              Actually, my post addresses two instances of sandboxing in Firefox:
              1. The Flash Player plug-in sub-process which is sandboxed using Windows low integrity levels (LILs)
              2. The HTML5 sandbox for iFrames (not related to LILs)

              For the Firefox process itself, it runs at medium integrity level on Windows Vista/7/8. As does the Java plug-in, if available to the browser.

              From a security perspective, which is more effective?
              o sandboxing the browser and browser plug-ins?
              Or
              o whitelisting frequently-visited web sites (for JavaScript, plug-ins, etc.)?

              Google’s Chrome browser does it all on Windows Vista/7/8, with the exception of sandboxing the Java plug-in. Internet Explorer 10 on Windows 8 sandboxes the browser as well as the Flash Player and PDF Reader plug-ins, but not the Java plug-in. I’ve been unable to determine the protection provided to Windows 7 users with Internet Explorer 10 (as I don’t have Windows 7 or 8). Would love to get more information on this.

              By default, Firefox does not support whitelisting frequently-visited web sites. One must install and correctly use the NoScript add-on.

              So, which provides more security to users? Sandboxing or whitelisting? Since Chrome supports both, it really highlights a philosophical diference between Internet Explorer and Firefox with NoScript as well as Opera (which has the capability for whitelisting built-in). Also, can ordinary users learn to proficiently whitelist their frequently-visited web sites? Would love to see more information on this as well.

              As I have written previously, I would like to see Microsoft make Enhanced Security Configuration available (read ‘optional’, and not the default) for Internet Explorer on its Windows client OSs.

              • “From a security perspective, which is more effective?
                o sandboxing the browser and browser plug-ins?
                Or
                o whitelisting frequently-visited web sites (for JavaScript, plug-ins, etc.)?”

                They address different things. Whitelisting for plug-ins (which IE can do too, just arm ActiveX Filtering and begin using your usual sites and whitelisting them) is a way of reducing exposure to proactively prevent exploitation. Sandboxing of the Windows processes isn’t a way of reducing exposure, but rather containing the damage if/when something DOES get exploited. And I’m sure you know all that as well as I do.

                In practice, both have their advantages, but when I consider that over 80% of the malicious websites today are legitimate sites that have been compromised, it doesn’t inspire confidence in whitelisting because a whitelisted site could turn harmful. NBC.com and Bible.com are a couple recent high-profile cases in point. If I had to choose (and this is from a guy who used to hunt live malware for a hobby), I lean towards mitigation. But one can certainly use both at once.

                If someone did want to use Enhanced Security Mode on a desktop version of Windows, I’d suggest simply cranking the Internet Zone security to High and enable ActiveX Filtering, then set Trusted Sites Zone to Medium-High with Protected Mode enabled, and add sites to Trusted Sites Zone as needed. I think your desire for the type of ESC found on Windows Server will vanish if you ever try it out… it’s not a user-friendly experience!

                Speaking of trying it out, if you’re interested, there’s 90-day trialware of Windows 8 Enterprise, and I think Windows 7 Enterprise as well.

                • Avast has an active script blocker that works well enough in my honeypot to make such work pretty boring, actually. I haven’t hit a java/adobe exploit for a long while. None that worked anyway. I used to get both, that at least tried to inject the package, but couldn’t because the batch file apparently held obsolete technology, and my fully updated applications shrugged the attack off onto the UAC, or simply failed.

                  Of course this new avenue taken by the developers will definitely be far superior to relying on heuristics. Simply designing the application to take advantage of the new NT x64 bit operating system hardening will go a long way. That is – if I’m interpreting all this correctly.

                • Rabid Howler Monkey

                  While IE ActiveX filtering does help with Active-X-based exploits (a very good and important feature, btw), my understanding is that it does not allow one to control the execution of JavaScript. Malicious JavaScript is every bit as dangerous as is malicious ActiveX. In addition, JavaScript runs in all modern web browsers on Windows, not just IE. Thus, it’s a much better tool if a miscreant wants his (or her) exploit to run across all web browsers.

                  Regarding the very recent NBC.com hack, that involved the miscreants inserting an iFrame on the web site that redirected users to a site under their control which attempted to load the Citadel malware on victims PCs:

                  http://blog.fox-it.com/2013/02/21/writeup-on-nbc-com-distributing-citadel-malware/

                  Whitelisting the NBC.com web site for JavaScript and plug-ins would have nipped this exploit attempt in the bud.

                  Trying to setup IE Enhanced Security Configuration on a Windows client OS won’t work because, while one can indeed modify IE settings in the Internet and Trusted Zones, one cannot improve the built-in whitelisting process to mimic the process available on Windows server OSs. And as an Opera whitelist user, I don’t believe it is any more onerous than is ESC for whitelisting web sites on Windows server OSs.

                  P.S. I agree that combining whitelisting frequently-visted (or legitimate) web sites and sandboxing provides enhanced protection. This is why I believe that the Chrome browser is the most secure web browser available on Windows, OS X and Linux. Whitelisting a web site could thwart an exploit that’s designed to escape a sandbox.

        • Rabid Howler Monkey

          Mozilla collaborated with Adobe to sandbox the Flash Player plug-in in Firefox on Windows. In addition, Mozilla has recently implemented the HTML5 sandbox for iFrames (frequently used in attacks):

          http://www.infoq.com/news/2010/01/HTML-5-Sandbox-IFrame

          [Google has implemented the HTML5 iFrame sandbox since Chrome version 4.0. Opera has as well since version 10.50. Microsoft, I believe, has included this feature in Internet Explorer 10.]

          That’s it for Firefox as far as I know.

          P.S. Proper use of the Firefox NoScript add-on to whitelist JavaScript and plug-ins for one’s frequently-visited web sites provides significant security. Hopefully, and back on topic, NoScript will allow one to whitelist sites for pdf viewing.

  4. i should just throw my windows computer out the window. thats the only way to be completely safe from exploits.

  5. Using two browsers, one with the Java (exploits) enabled is still a great way to compromise your computer. I’ve never understood how compromising your computer =through= one browser while leaving your primary browser “protected” makes sense. It does not. Unplug the Java plugin from all browsers is the right course to take. The two browser idea protects NOTHING.

    • The idea is to minimize exposure. For example, some uninterruptible power supply units from APC or Tripp-Lite are configured using a Web browser and a Java applet. That might be your only need for Java in a browser. So if you have one browser used only for configuring your UPS unit, and another browser used for all other browsing, you have nearly zero exposure.

      Instead of configuring your uninterruptible power supply, for some people it might be a website they must use, which requires Java. Maybe it’s their bank, or GoToMeeting, or a business application. Using the Java-enabled browser only for those sites, and a Java-free browser for all others, will reduce exposure monumentally. If one of those sites gets compromised or DNS-hijacked, then yeah, there’s the fly in the ointment. But it’s better than nothing.

  6. Prepare for the next JAVA round.

    PoC for Issues 54 and 55
    complete Java security sandbox bypass

    http://www.security-explorations.com/en/SE-2012-01-poc.html

  7. Quit all the whining. Install sandboxie. Sandbox your operating system, then let the sandboxes of firefox or adobe do ‘some’ of the work.

    I force my media player, pdf reader (foxit), Internet Explorer, and Firefox to all open in their own dedicated sandbox via Sandboxie. Once I am done with any browsing or downloading of malware, Sandboxie deletes the contents after the session closes (which is very often). It’s a simple, single software solution. Once configured it’s completely transparent.

    This way it works the same even in a two browser environment.

    • Rabid Howler Monkey

      Who’s whining? :)

      Sandboxie is a great tool and is recommended by Brian here:

      http://krebsonsecurity.com/tools-for-a-safer-pc/

      A 3rd party sandbox on Windows, such as Sandboxie, is the only relatively easy way to sandbox the Java plug-in processes if one needs to run Java applets in their web browser.

      P.S. One could also create a sandbox to open Microsoft Office documents either downloaded from the Internet or attached to email. Assuming that one is not running Microsoft Office 2010 or 2013 on Windows Vista/7/8.

  8. And yet another version of Flash is out today – 26th. Version 11.6.602.171 for most platforms.