Saturday, February 13, 2010

Adobe's javascript issue


I was reading this article from Threat post where Adobe's security chief Brad Arkin had  interviewed by Threat-post editors Dennis Fisher and Ryan Naraine. It was long but interesting conversation with Brad Arkin explaining about what the recent malware exploit and what really went wrong and how there team responded to this  exploit. Questions from Dennis and Ryan were more straight to the point and made more sense on adobe's reply on this issue. It is interesting to know how impossible it is to completely remove javascript without causing major compatibility problems.  But it is a lengthy conversation and here are the few very informative key points.
JavaScript black list:
i am not sure how many of you out there are aware of the JavaScript blacklist function a new feature that shipped along with their October update. JavaScript blacklist will allow users to define any specific javascript API as a black list item, which than wont be called. By putting a javascript into the black list, any PDF document that it attempts to call that will be denied. it’ll deny valid calls as well as malicious calls that try to corrupt the call to create a crash. And this is something users can do, and also administrators for managed desktop environments can also do this using group policy objects to roll-out the change as a registry key.
Document.netplayer:
The actual malware identified in adobe flash and adobe reader is in an API called Document.netplayer. Brad's response for the possible disruption this API can cause is
Docmedia.newplayer is not one of the new API calls that is showing-up in every single PDF that we see.  It’s something that’s used a lot less often.  And so, if you were to disable JavaScript altogether, that would disrupt a lot of things.  Disabling this here, you know, for the people who rely on it, obviously, it would disrupt what they’re doing.  But, the majority of PDFs that use JavaScript don’t have this in it.  And so, for most users, their experience and their workflows are gonna be the same.  It’s something that, you know, enterprises need to understand what’s in their workflow so they can check what the impact would be.
Mitigation:
  • Utilizing the JavaScript black list function.  This is the most powerful mitigation.  It completely protects users against the attack, and at the same time it will cause the least disruption for legitimate uses of the program.
  • Something that’s a lot more disruptive, but also completely mitigates the current attack is disabling JavaScript altogether
Adobe's steps to mitigate future attacks:
Back in May we announced this security initiative that the Reader and Acrobat engineering teams were working on.  And the – the three big legs of that process, we were doing – improving our process for urgent patch release, and then moving through the quarterly security update cycle.  But, the most important thing that we were doing there was the code hardening activities, and a big part of the code hardening, for us, was looking at the JavaScript APIs and doing things like looking for problems and fixing them, but also tightening up input validation, so that even if there might be a latent bug somewhere deep in the code that we don’t know about, if we can prevent the ability of the attacker to get malicious data to that weak spot in the code, then that’ll protect against the problem.  And so, tightening-up the input validation, working on, you know, any potentially risky areas and seeing what we could do there.
Why don't you just remove JavaScript support from Adobe Reader?
No.  JavaScript is really an integral part of how people do form submissions.  And so, anytime you’re working with a PDF where you’re entering information, JavaScript is used to do things like verify that the date you entered is the right format.  If you’re entering a phone number for a certain country it’ll verify that you’ve got the right number of digits.  When you click “submit” on the form it’ll go to the right place.  All of this stuff has JavaScript behind the scenes making it work and it's difficult to remove without causing problems.
Flash cookies
Flash player local shared objects, because they behave quite differently from browser cookies.  But, the local shared object is something that – what we find is that there’s a lot of great uses for that where the developer will store data locally, it’ll improve network performance, it’ll improve the user experience where they can queue stuff up immediately and not having to wait for network latency.  But, then we’ve see there’s some confusion about how to manage the local shared object, and then also there’s things that subvert the user’s intention where, you know, we’ve seen things like this respawning that you talked about.  And so, our goals are to make it as easy as possible for the user to exercise whatever it is they’re intending to do.  And it’s actually not any harder managing local shared objects through Flash Player in terms of just, if you measure the number of clicks required.  It’s just, it’s less familiar to users, and so people know how to go to their browser file menu and click on, you know, “clear cookie cash.”
But, doing those same clicks for Flash Player is something that people aren’t as familiar with, and we for a long time have tried to work with the web browser vendors for them to open-up the API, so that when the user clicks “clear browser cookies,” it’ll also clear the Flash Player local shared objects.  But, the browsers don’t expose those APIs today.  And so, that’s something that we’ve been working with those guys, because if they can make that open up that API ability, then we can hook into that as Flash Player, so that when the user clicks “clear” it’ll clear Flash Player as well as the browser cookies.
For complete story click here. Now its time for me to research how possible is to get browsers to clear the flash cookies along with browser cookies when user clicks "clear it"?  If you got any ideas please do comment..