There was recently another news story about a PDF document not being redacted properly. As a result, sensitive information leaked out. We’ve covered this topic before, but we’ll cover it from a different angle this time…
Well, you’ve experienced us in print…now see us in these exciting, new moving pictures! Listen to John Landwehr and John B Harris discuss Adobe’s key information assurance capabilities and how they can help you achieve content-centric security with products that provide integrity, confidentiality, authentication and privacy.
Some of our savvy readers and users may have already noticed a dialog box asking them to download a “security settings update from Adobe Systems”:
No, it’s not the latest patch. In fact, by clicking Yes, Acrobat and Reader 9+ users are downloading an update to the Adobe Approved Trust List (AATL), a list of trusted digital certificates that provides users with better assurances that the digitally signed documents they are receiving can be trusted. This is visible to document recipients as a green check mark or blue ribbon, depending on the type of digital signature.
In this update, four certificates, two each from Entrust and QuoVadis respectively, have been added to the AATL…
David Lenoe here. Wendy Poland and I will be presenting at SOURCE Boston this Thursday, April 22. Here’s a description of the session we’re presenting: Bullseye on Your Back – Life on the Adobe Product Security Incident Response Team
Ubiquity can come at a price: Experience has shown that the more popular and widely deployed an application is with end-users, the more likely that application will become a target for attackers and good security researchers alike.
Available in 34 languages, on all major platforms, and just about every desktop/laptop, it’s no surprise that Adobe Reader has made the lists of top applications targeted in 2010.
Join this session, and hear David Lenoe and Wendy Poland, members of the Adobe Product Security Incident Response Team (PSIRT), talk about the challenges of having the bullseye on your back and the hard lessons learned in the process. In looking at a recent zero-day vulnerability, Dave and Wendy will offer insight into Adobe’s product security incident response, the process of acting on vulnerability reports, and the analysis that goes into developing a schedule for a fix.
Live and learn–you could be taking center stage before you know it!
Please stop by and say hi if you’re at SOURCE!
Kyle Randolph here. I will be attending Black Hat Europe this week as part of ASSET’s security community outreach effects. If you are interested in discussing Adobe security, please shoot me an email (krand at adobe dot com) and we can meet up. Looking forward to discussing application security with other folks in the security community this week!
One of the common themes I promote when speaking publicly about software security is the importance of staying up-to-date. Most users who ever encountered a security problem using Adobe products were attacked via a known vulnerability that was patched in more recent versions of the software. This is why we’ve invested so much in the new Adobe Reader Updater that goes into full production with our Tuesday April 13, 2010 release. (For more details on the new updater, see Steve Gottwals’ Adobe Reader blog post titled “Upcoming Adobe Reader and Acrobat 9.3.2 and 8.2.2 to be Delivered by New Updater.”)
We’re also hard at work on ways to better protect our enterprise users in managed desktop environments by collaborating closely with Microsoft to make it easier for Microsoft System Center Configuration Manager (SCCM) and Microsoft System Center Essentials (SCE) customers to import Adobe updates through the Microsoft System Center Updates Publisher (SCUP) and manage their distribution to client computers. We’ll have more details to share later in the year as work progresses.
Given this emphasis on staying up-to-date, we have been fielding questions about why the Adobe Download Center at http://get.adobe.com/reader/ doesn’t always serve the most recent version of Adobe Reader. (For instance, when the April 13, 2010 update goes out, the latest version of Adobe Reader will be 9.3.2, while the Download Center will offer version 9.3.0.) Since the explanation does not fit into the 140 characters of a tweet, let me provide more insight into the reasoning here:
Historically, the decision was based on resource allocation trade-offs and windows of risk. The Adobe Reader Download Center landing page offers more than 70 different full installers representing each supported language and platform pair. Each must be fully tested, and then the Download Center itself must be tested to make sure the correct language/operating system installer is offered to the various browser/language/operating system requests to the site. Despite all of the automation in place, this total effort still represents thousands of person-hours. For a “double-dot” release like 9.3.2, we only produce an update, which does not involve creating and testing full installers. This allows us to get the update out the door as soon as it is available.
The intended behavior of the update mechanism in the product is that it will check for updates the first time Adobe Reader executes after an installation. When everything works as intended, users get updated to the latest version the first time they run the product.
With all of that said, our commitment to protect our users is a key priority for us, and our continued efforts to help close the window of exposure to vulnerabilities is part of that commitment. As I mentioned earlier, the majority of attacks we are seeing are exploiting software installations that are not up-to-date with the latest security updates, which suggests that far too many users are currently not installing the security updates that would protect them. The new updater technology was designed to address part of this problem.
In addition, we are working on making a change to some of the language/operating system versions of Adobe Reader hosted on the Download Center. Starting with the next quarterly security update for Adobe Reader, currently scheduled for July 13, 2010, we will update the Download Center to offer an installer for the latest version of Adobe Reader for the English, German, Spanish, Japanese and French language versions for Windows, and the English version for the Mac. Today, these platform/language pairs represent the overwhelming majority of Adobe Reader downloads. With this change to the Adobe Reader Download Center, we believe we can help even more users get to the latest, most secure release and continue to drive the message of how important it is to stay updated.
We are constantly engaged in security process improvement efforts in order to strengthen the protection for our customers. This includes methods of reducing the window of exposure to vulnerabilities to make sure end-users are rapidly protected against quickly evolving threats as well as stronger controls within the product itself. Therefore, we always follow a strategy to protect the greatest number of end-users as expediently as possible. As we continue to make improvements to the security posture of our products, we’ll continue to communicate dates and details via the ASSET blog.
Steve Gottwals has posted to the Adobe Reader Blog regarding Didier Stevens’ recent report on a social engineering attack which relies on the “/launch” functionality in the PDF specification. Mitigation information for consumers and administrators is included. You can find the full post here.
Today’s post will cover a variety of other other improvements we’ve made to LiveCycle Rights Management ES2.
First, extending our previous capabilities to revoke documents and offer version notification, we now offer out-of-the-box “Revoke and Replace” functionality. By using LiveCycle Content Services as your document repository, you can make sure that every “major version” that is checked in supersedes any version people may have cached locally elsewhere. More info:
Second, our Extension for Office now offers dynamic visible watermarks much like we have offered previously for PDF files viewed within Acrobat and Reader. This means that you can exchange protected Word, Excel, and PowerPoint files that visibly display the recipient’s name, email address, and the time they opened the document. More info:
Third, for developers out there who need to create policies programmatically, we’ve offered significant improvements in how our orchestration APIs work. More info:
Finally, customers have asked for additional flexibility in managing audit event records that track the history of a document. With the latest release you can export, archive, and delete event history specifying who has opened, modified, printed, etc, your protected documents. More info: