Brainfoldb4u's Blog

Just another weblog

Posts Tagged ‘Adobe’

Adobe blacklisting framework

Posted by brainfoldb4u on January 11, 2010

As abode said it is not practically feasible to disable whole of javascript in adobe, it introduced a feature called black listing. This allows users to define any specific javascript API as a black list item, which then it wont be allow it to be called. Say we found a vulnerability in docmedia.newplayer, you can add this to black list and hence you can safeguard your system by doing so.
By putting that into the black list, then any PDF document that it attempts to call that, that call will be denied.  And so, it’ll deny valid calls as well as malicious calls that try to corrupt the call in order to create a crash. And this is something individual 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. Below video should demonstrate on how to add a javascript function to blacklist item.

Given that Adobe currently has no automatic updates in place, my question is how will a normal user will get to know what needed to be blacklisted. This fix may help the technical users but for average user they have to wait for adobe’s next major update which is likely to be within next three months.

Posted in Exploit, Hacking, Information Security, Vulnerability | Tagged: , , | Leave a Comment »

Flash cookies

Posted by brainfoldb4u on January 8, 2010

Flash-cookies (Local Shared Objects, LSO) are pieces of information placed on your computer by a Flash plugin. Those Super-Cookies are placed in central system folders and so protected from deletion. They are frequently used like standard browser cookies. Although their thread potential is much higher as of conventional cookies, only few users began to take notice of them. It is of frequent occurrence that -after a time- hundreds of those Flash-cookies reside in special folders. And they won’t be deleted – never.

Some flash cookies properties are

  • They are never expiring – staying on your computer for an unlimited time.
  • By default they offer a storage of 100 KB (compare: Usual cookies 4 KB).
  • Browsers are not aware of those cookies, LSO’s usually cannot be removed by browsers.
  • Via Flash they can access and store highly specific personal and technical information (system, user name, files,…).
  • Ability to send the stored information to the appropriate server, without user’s permission.
  • flash applications do not need to be visible
  • there is no easy way to tell which flash-cookie sites are tracking you.
  • shared folders allow cross-browser tracking, LSO’s work in every flash-enabled application
  • the company doesn’t provide a user-friendly way to manage LSO’s, in fact it’s incredible cumbersome.
  • many domains and tracking companies make extensive use of flash-cookies.
  • These cookies are not harmless.

In order to track our flash cookie information we need to go to Adobe flash web site. There will a setting manager , its a special control panel that runs on your local computer but is displayed within and accessed from the adobe website. Adobe has no access to these setting, its completely users responsibility to change the setting as he requires it. Click on this link to access your security manager setting.  To change your settings, click the tabs to see different panels, then click the options in the Settings Manager panels that you see on the web page. The five tabs are Global storage settings, Global security settings, Global notification settings, website privacy settings, website storage settings.  To read more about those tabs click here

When SWF or FLV content is being played, the settings you select for Flash Player are used in place of options you may have set in your browser. That is, even if you have specified in your browser settings that you do not want cookies placed on your computer, you may be asked if an application that runs in Flash Player can store information. This happens because the information stored by Flash Player is not the same as a cookie; it is used only by the application, and has no relation to any other Internet privacy or security settings you may have set in your browser.

Similarly, the amount of disk space you let the application use has no relation to the amount of disk space you have allotted for stored pages in your browser. That is, when SWF or FLV content is being played, the amount of disk space you allow here is in addition to any space your browser is using for stored pages.

No matter how you may have configured your browser, you still have the option to allow or deny the application that runs in Flash Player permission to store the information, and to specify how much disk space the stored information can occupy.


Firefox Extension Better Privacy is a cookie manager for LSO flash objects and DOM storage objects. Local storage objects are placed on the computer by a flash application like the YouTube video player.

BetterPrivacy can stop them, . by allowing to silently remove those objects on every browser exit. So this extension becomes sort of “install and forget add-on”. Usually automatic deletion is safe (no negative impact on your browsing), especially if the deletion timer is activated. The timer can delay automatic deletion for new or modified Flash-cookies which might be in use. It also allows to delete those objects immediately if desired.

With BetterPrivacy it is possible to review, protect or delete new Flash-cookies individually. Users who wish to to manage all cookies manually can disable the automatic functions. BetterPrivacy also protects against ‘DOM Storage’ longterm tracking, a browser feature which has been granted by the major browser manufactures.

To know more about flash cookies and how to’s click the following links

Recommended comprehensive Flash cookie article (topic: UC Berkeley research report)

Wikipedia LSO information:

Privacy test:
Navigate to BetterPrivacy (right column)

Posted in Browser Security, Information Security | Tagged: , | Leave a Comment »

Adobe's javascript issue

Posted by brainfoldb4u on January 7, 2010

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.


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.


  • 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..

Posted in Exploit, Information Security | Tagged: , | Leave a Comment »

Open source fix for flash security holes

Posted by brainfoldb4u on January 2, 2010

Open source solution for Flash security holes:

To prevent the frequently recurring security issues in Adobe’s software from being exploited, Felix “FX” Lindner of Recurity Labs presented his open source “Blitzableiter” (lightning rod) project at the 26th Chaos Communication Congress (26C3). The tool analyses and cleans up Flash code before playback and is designed to prevent security holes in Adobe Flash from being exploited. Flash is one of the most commonly used points of entry for attackers who try to compromise PCs during visits to web pages. the Blitzableiter tool checks SWF files for their integrity. Embedded ActionScript code is detected, analysed and cleaned up. The wrapper can also verify whether embedded objects such as JPEG images comply with the specification.

To read the full article from H-Secure, click here

Previously, Adobe was warning of a new zero-day vulnerability in its popular Reader and Acrobat applications that is being actively targeted by attackers in the wild.

In an advisory released mid December,, Adobe acknowledged reports from several security vendors that a new malicious PDF file was discovered in some email attachments targeting the Adobe flaw. Adobe said the remote code execution vulnerability is in Reader and Acroobat 9.2 and earlier versions

To learn more about adobe zero day vulnerability, click here

Posted in Information Security, Open Source, Security tools | Tagged: , , | Leave a Comment »