Posts tagged "Flash"

Reflections on Pwn2Own

Returning from CanSecWest left me reflecting on how the Pwn2Own competition has evolved over time. A lot has changed in the Pwn2Own competition over the years. The event has grown in attendance, competitors, and complexity, just as the industry has grown.

For the first contest in 2007, no one competed on the first day. Shane McCauley called fellow security researcher Dino Dai Zovi in NYC that night and urged him to compete. Dino was able to write the exploit over night and win the contest on the second day. Visually, the attacks seem no different from year to year. The contestant sits down at the machine, and “seconds” later the calculator (or notepad in this year’s case), pops up on the screen.  However, the preparation for the attacks from 2007 to 2016 are now drastically different, with contestants preparing attacks weeks in advance.

Media coverage around security advisories is often just a run down of how many CVEs a vendor released that month. People often imply from these articles that all the CVEs are easily exploitable and trivially weaponizable. This can lead to false perceptions that exploiting the software is a simple task. In reality, a CVE from a vendor is not a guarantee of exploitability. Even if the CVE can give the attacker the ability to overwrite memory, that is not a guarantee that it can be weaponized. Technologies such as ASLR (Address Space Layout Randomization) weren’t even released for Mac OS X when Dai Zovi competed in 2007. Today’s attackers have to work around defenses such as CFG (Control Flow Guard), Isolated Heaps, and a number of other technologies designed to prevent a crash from becoming an exploit.

In addition, competitors have to deal with the fact that the contest frequently occurs after Patch Tuesday where a vendor’s security improvements could interfere with their attack. Adobe has been aggressively adding mitigations to Flash Player over the last few months. In our release the week before the contest, we added changes to zero memory more often and leveraged the Windows’ low fragmentation heap. Both Adobe and Google found that some of the contestant’s entries overlapped with recent security reports. Part of the reason for the increasing payouts for the winners comes from the fact that the targets for the competition all have active security teams and external communities that are constantly working to improve the platform. As the community and vendors continue to mature their software, bug or mitigation collisions become more of a material risk for competitors. While it may not seem like it on the surface, the attackers are trying to hit moving targets.

The Flash Player updates prior to the contest led to some failed attempts at the competition. The failed attempts were by teams who had already won under different categories. Therefore, the competitors were clearly highly skilled and had already proven themselves to be capable of weaponizing exploits for the target platform. The reality is that what they are attempting to do is not easy and the failures serve to remind us how hard it is to get those wins. When any competition gets to a certain level, even the most skilled players are going to experience some losses.

That said, the contest always has its share of winners. Those wins demonstrate that there is always more that vendors can do in order to improve security. While the individual bugs help, Pwn2Own is truly valuable because it shows how different researchers will try to bypass the existing mitigations to create the fully weaponized exploit. That insight into different attack approaches inspires us as vendors to come up with the next generation of defenses.

Like many pros, the winning contestants always make it look easy. Although, as an industry we are often too quick to lump everything in the same “it is easy because it is completely vulnerable” bucket. Companies like Adobe, Microsoft, and Google are in a constant sprint with attackers. The security industry has progressed from the days of just trying to write clean, well validated code. Today, we are adding in large platform features that serve no other purpose than trying to thwart attackers. These types of features are added at an increasingly frequent basis. The companies who are on the front line of this battle will change and grow over time. It is important for those vying to one day be on the defender’s side of Pwn2Own to understand the current table stakes.

Overall, Pwn2Own is a fun contest to interact with security researchers and to push the industry forward. Beneath the high level pageantry of smoking jackets and large prizes, is a low-level escalation between offensive and defensive strategists. While the visual results from watching in the room seem similar from year to year, the innovation and challenge required to achieve those results increases every year.

Peleus Uhley
Principal Scientist

CanSecWest 2012

The team and I are about to head off to CanSecWest. While I have been attending CanSecWest for several years, this year will be a unique experience for me. During my talk, I will demo an open-source tool I just released, called Adobe SWF Investigator. The tool can be useful for developers, quality engineers and security professionals for analyzing SWF applications. It has been a pet project of mine for some time, and I decided to share it with a broader audience.

Within my current role, I have to look at all aspects of SWF applications from cross-site scripting issues to binary analysis. Therefore, the tool includes capabilities to perform everything from testing cross-site scripting to viewing the individual SWF tags within the file format. I am hoping that by releasing the tool as an open-source ActionScript application, it will encourage all ActionScript developers to learn more about security. The tool is designed to be an extensible framework everyone can build upon or modify. More information on the tool can be found in my DevNet article.

In addition to demonstrating the tool, I will also be talking about Advanced Persistent Response. Adobe has been the focus of hackers for some time, and I plan to discuss what we have learned and observed in the process of responding to those threats. My talk will be on Wednesday at 3:30pm, if you are interested. When I am not speaking, you can probably find me and the Adobe team either at the Adobe table or milling around the pwn2own contest for no particular reason. Please feel free to come by and talk with us. See you there!

Flash Player 11 Privacy and Security Updates

You may have seen our Flash Player 11 announcement earlier today. In addition to the major advancements for gaming, media and data-driven applications, this new version of Flash Player, which will be available in early October, will include several important new privacy and security features. We’ll start with privacy:

Extending Key Privacy Capabilities to Mobile Devices

Adobe has been working hard to make it easier for users to control their privacy and privacy settings on their desktops. We added support for the private browsing feature found in many Web browsers when we introduced Flash Player 10.1, created a desktop version of the Flash Player Settings Manager (aka a native control panel) and redesigned the Flash Player Settings Manager interface in Flash Player 10.3. And we worked closely with the browser community to allow end-users to clear their Local Shared Objects (LSOs) through their existing browser controls—functionality that was also introduced in Flash Player with the release of Flash Player 10.3.

With Flash Player 11, we are extending key privacy capabilities to tablets and mobile devices. Privacy is important regardless of the device you are using. With the release of Flash Player 11, we are bringing support for private browsing mode (aka incognito mode)* and a mobile control panel to Android devices. This means that end-users will be able to leverage the same private browsing mode protections available to them on their desktops today on their mobile devices, while the new mobile control panel will make it easier for them to manage their Flash Player privacy settings on their Android devices. (*Private browsing mode, or incognito mode, is supported on Android Honeycomb.)

The mobile control panel will launch the browser on the device and take the user to the online mobile settings manager, which allows users to control two of the mobile Flash Player features:

  • The first are the settings for controlling Local Shared Objects (LSOs). Users can choose to “always” allow local storage, allow local storage “only from sites I visit” or “never” allow local storage. The settings manager also provides a handy “clear [all] local storage” option.
  • The second feature that can be controlled is peer-assisted networking which allows Flash Player to use connection sharing to provide a better media experience.


New Security Features in Flash Player 11

On the security front, we are introducing several new features that will allow developers to better protect customer data. The first major new feature we are adding is support for SSL socket connections, which will make it easier for developers to protect the data they stream over the Flash Player raw socket connections.

We are also adding a secure random number generator. Flash Player previously provided a basic, random number generator through Math.random. This was good enough for games and other lighter-weight use cases, but it didn’t meet the complete cryptographic standards for random number generation. The new random number generator API hooks the cryptographic provider of the host device, such as the CryptGenRandom function in Microsoft CAPI on Windows, for generating the random number. The native OS cryptographic providers have better sources of entropy and have been peer reviewed by industry experts.

Lastly, the introduction of 64-bit support in Flash Player 11 brings with it some security side-benefits: If you are using a 64-bit browser that supports address space layout randomization (ASLR) in conjunction with the 64-bit version of Flash Player, you will be protected by 64-bit ASLR. Traditional 32-bit ASLR only has a small number of bits available in the memory address for randomizing locations. Memory addresses based on 64-bit registers have a wider range of free bits for randomization, increasing the effectiveness of ASLR.

Overall, our security and privacy roadmap still has much more to come, and we are already working on the next generation of features for upcoming releases. To take a look at the many new features in Flash Player 11—whether it be the advancements for gaming, media and data-driven applications, the security enhancements or the new mobile privacy features—check out the release candidate of Flash Player 11 for desktops now available on Adobe Labs or watch for an announcement once Flash Player 11 for desktops and Android devices becomes available in early October. We look forward to your feedback!

Lindsey Wegrzyn, Senior Product Manager, Privacy
Peleus Uhley, Platform Security Strategist