Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    June 2013
    S M T W T F S
    « May   Jul »
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    30  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for June 17th, 2013




    About two weeks ago, Oracle published a blog post describing – and promising – to improve the security of Java. Since then, I’ve been asked a few times: what exactly did they say, and what does it mean for end users?

    First, Oracle talked about how they’re now handling security patches. They pointed out how recent patches had, in fact, solved more security holes than previous patches. What’s more important to take away is that Java’s update schedule has been brought in line with other Oracle products: it will receive patches every three months, starting in October of this year. This should help get potential problems fixed more quickly before they are exploited by attackers. Of course, Oracle will continue to deliver out-of-band updates as needed for critical vulnerabilities.

    Java has also been brought under Oracle’s Software Security Assurance policies. As part of this, for example, Oracle will now use automated security testing tools to prevent regressions and new issues from showing up when a bug is fixed. This is welcome news, as it means that bugs will be patched more quickly in the future.

    Next, they discussed how they had been working to improve the security of Java as it is used in browsers. More important than the discussion of what was done in the past is what Oracle will implement soon: future Java versions will no longer allow unsigned or self-signed apps to run. It’s not clear when this will happen, but if it does, it will be a significant increase in Java security. It means that attackers will have to acquire or compromise a code signing key to get their Java applets to run: while this will not stop a truly determined attacker, less targeted attacks will fail.  In addition, Oracle is also working to improve how Java processes revoked signing signatures, so that this process can be turned on by default at a later time.

    For enterprise users, there’s good news too. Future versions will add support for security policies enforced by Windows itself, so that system administrators can set network-wide policies that can restrict or relax Java usage without having to set these per system. In addition, a new type of Java distribution – Server JRE – is being created specifically for servers running Java apps. This distribution will have several libraries removed to reduce the potential attack surfaces.

    All of these changes are for the better – Oracle is acknowledging that there have been challenges when it comes to Java security in the past, and they’re working hard to improve it moving forward. We appreciate these efforts and hope that they succeed in reducing the threat from Java exploits, which is completely in line with Trend Micro’s goal of creating a world safe for exchanging digital information.

    In the meantime, we strongly urge that users do their part to keep their Java installs safe: update to the latest version of Java. We earlier discussed how to secure Java in the blog post How to Use Java – If You Must.

     
    Posted in Vulnerabilities | Comments Off


    Jun17
    12:56 am (UTC-7)   |    by

    At the end of May, two Google security engineers announced Mountain View’s new policy regarding zero-day bugs and disclosure. They strongly suggested that information about zero-day exploits currently in the wild should be released no more than seven days after the vendor has been notified. Ideally, the notification or patch should come from the vendor, but they also indicated that researchers should release the details themselves if the vendor was not forthcoming.

    This is a pretty aggressive goal. Microsoft, for example, does not set public deadlines for critical patches: a balance needs to be found between quality and speed. Balancing the two is not that easy. On one hand, an actively exploited vulnerability will be used by malware writers aware of the vendor’s vulnerability. On the other hand, a quick patch could have negative side effects and could cripple the application or the entire system.

    Almost every security vendor has false positives that result in negative side effects. We have lots of safeguards in place – such as checking against whitelists – but Murphy’s law applies. Our industry has crippled the computers of users. What more an operating system vendor – they need to be extra careful in patching. They need to conduct proper quality assurance, as the patch will affect millions of computers.

    In my opinion, disclosure after 7 days is reasonable and OK, but expecting a patch in this time frame is unreasonable. Let’s see how Google itself will manage. Currently, there’s a Google Android Trojan spreading which is able to hide itself from the “Device Administrator”, which renders it invisible from security programs and clean up attempts. This was possible because of a security flaw in Android. Will Google be able to fix this within 7 days? Let’s see…

    The bigger debate is not just about how long it should take to report and fix vulnerabilities. It’s about how vulnerabilities should be reported in the first place. If you believe a recent media report, the US government is now the biggest purchaser of malware. How do we ensure that the affected vendors are informed, that these are not used for offensive uses like Stuxnet? How do we ensure that these same vulnerabilities don’t end up in the hands of the underground, which will use these threats widely?

    What needs to take place is a bigger discussion around how discovered vulnerabilities are dealt with at all. These should be between all those involved in this field – developers, governments, and researchers – to determine how we can deal with security vulnerabilities in the future.

     


     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice