Author Archive: Adobe Product Security Incident Response Team

Inside Adobe Acrobat Protected View

Kyle Randolph here, along with the security team for the Adobe Acrobat family of products. This post will discuss the technical details of the new Protected View added in the Acrobat 10.1 release announced today. Even more technical details are available in the Application Security Library.Protected View builds on Adobe Reader Protected Mode discussed previously in a series of technical posts on the ASSET blog. With Protect View, Acrobat users will benefit from the protection provided by a sandbox when they open untrusted PDF files.

Design Principles

The high-level security design principles for Protected View include the following:

  • As secure as Adobe Reader Protected Mode: Acrobat leverages the same sandbox technology and implementation as Adobe Reader.
  • PDFs in a browser offer Adobe Reader Protected Mode functionality and protection, along with “rights-enabled” features: Protected View in a browser offers a similar experience to Adobe Reader Protected Mode, plus the features that are available in Adobe Reader for rights-enabled documented are always available for Acrobat Protected View users.
  • Trust can be assigned to documents so that they bypass Protected View restrictions: Because of its integration with Enhanced Security, users can specify files, folders and hosts as privileged locations that are not subject to Protected View trust restrictions. PDFs originating from a privileged location will not open in Protected View.

Standalone Application

In the standalone application, behavior is simple and parallels the Protected View provided by Office 2010. During a file download and/or save, Web browsers and e-mail programs typically mark downloaded files and attachments with a “potentially unsafe” flag. When you open such a document, Acrobat displays a warning bar at the top of the viewing window. In this state, many of the Acrobat features that interact with and change the document are disabled, and the associated menu items are greyed out in order to limit user interaction.

The view is essentially read-only, and the disabled features prevent any embedded or tag-along malicious content from tampering with your system. Once you’ve decided to trust the document, choosing Enable All Features exits Protected View, enables all menu items, and provides permanent trust for the file by adding to Enhanced Security’s list of privileged locations. The document is now open in a full, unsandboxed Acrobat process.

Browser

When a PDF file is opened in a browser, Acrobat Protected View provides a streamlined experience that doesn’t utilize a warning bar. Instead, browser-based PDF files provide an Adobe Reader-like experience for documents that have been “rights-enabled.” That is, all of the Adobe Reader features are available in addition to features that become enabled when a document author uses Acrobat to extend features to Adobe Reader users. These features include signing existing form fields, adding new signature fields, saving form data, etc.

Table 1 Protected View: Standalone versus Browser Functionality

Feature Standalone Browser
Drag-drop PDF files to the reading or navigation pane No Yes
Printing No Yes
Advanced Printing No No
Saving No Yes
Pan and Zoom No No
Loupe Tool No No
Reading Mode No Yes
Full Screen Mode No Yes

 

Integration with Enhanced Security

Acrobat Protected View is integrated with Enhanced Security both in the user interface as well as at the registry level. When a user chooses “Enable All Features,” the current file is added to the user’s list of privileged locations, thereby granting a level of trust which allows it to bypass the Enhanced Security restrictions. Those restrictions include such things as cross-domain access, data injection, silent printing, etc. For this reason, you should only enable all features for documents you absolutely trust.

The application stores information about privileged location trust in the registry. Once a file is trusted, a unique identifier is added to each of the cabs under the cTrustedFolders registry key. Conversely, if a file is trusted at the registry level manually or via some other feature like the Options button on the Yellow Message Bar, that file becomes exempt from Protected View from that point on.

It’s all a matter of what you trust: Protected View, Protected Mode, and Enhanced Security provide restrictions to safely open documents that you do not trust; however, you can also bypass those restrictions for files, folders and hosts you that deem trustworthy. You control the level of security you need.

Conclusion

The Acrobat Protected View sandboxing solution is a great way for protecting users from malware PDF attacks. In the protected view the user will have very limited access to the Acrobat functionality as such, but it’s just enough to make an informed decision as to whether he/she wants to trust the document or not. And its design allows the user to read the contents of a PDF file received from untrusted sources without having to worry about a system compromise due to malware infection. The yellow bar indicator at the top allows transition into the normal editing mode of Acrobat once the document has been explicitly trusted by the user. Sandboxing adds another layer of defense to the overall Acrobat product security. It’s not a silver bullet, but it can go a long way in protecting our customers and users from most of the commonly known attacks out there.

-Kyle Randolph, Ben Rogers, Suchit Mishra

 

 

The Latest on Adobe’s 2011 Conference Schedule

Hi there!

 Steve here, checking in to give you an update on where the Adobe product security team’s travels are taking us next.

 Brad Arkin will deliver the Thursday keynote at the 2011 OWASP AppSecEU Conference in Dublin, Ireland on June 10, 2011.

 As the Chair of FIRST.org I’ll be presiding over FIRST’s 23rd annual conference in Vienna, Austria, from June 12-17, 2011. The Adobe PSIRT group manager, David Lenoe, will also be in attendance.

The next stops after this will be other conferences in North America, such as REcon 2011 in Montreal, Canada, and (our favorite) Black Hat 2011 USA in Las Vegas. Bryan Sullivan’s Black Hat talk on “Server-Side JavaScript Injection: Attacking NoSQL and node.js” has already been accepted.

See you there!  :-)

Steve aka  “Cap’n Steve”  Adegbite

NoSQL Security Slides

Thanks to everyone who came out to the OWASP LA event last night, it was a great meeting! I’ve had a ton of people write me for the slides, so I’m putting them up here for everyone. Be sure to view the annotations, there’s lots of background information in the presenter’s notes.

Thanks!
-Bryan

NoSQL, But Even Less Security

Hi all, Bryan here. If you’re in the Los Angeles area, I’d like to invite you to the presentation I’ll be giving at the OWASP LA chapter meeting on Wednesday, April 27th, titled “NoSQL, But Even Less Security.” We’ll be taking an in-depth look at some programming “worst practices” that can lead to vulnerabilities in applications using NoSQL databases such as MongoDB, Riak, CouchDB, Neo4j, or Cassandra. Here’s a sneak peek at some of the problems I’ll be talking about:

Eventual consistency. According to Eric Brewer’s CAP theorem, at any given time a system has to give up either consistency, availability, or partition tolerance: It’s impossible to always have all three. For many organizations, the whole reason they’re moving away from traditional relational SQL databases is that they want to improve scalability (i.e. partition tolerance). Since the CAP “P” is a hard requirement, you have to choose between consistency and availability, and some NoSQL databases choose availability. These are called “eventually consistent” databases, because at any given time you can’t be sure you’re seeing up-to-date data. Of course, to a security person, “eventual consistency” is just a fancy way of saying “race condition,” so we’ll be demonstrating some of those.

CSRF and REST APIs. Authentication and authorization are very weakly implemented in most NoSQL databases, if they’re implemented at all. Usually, if you can get to the port where the database is running, you have complete administrative access to it. Even assuming that you’ve closed off outside access to those ports with your firewall (I hope this is a good assumption!), you may still be vulnerable to cross-site request forgery attacks against the database REST APIs.

NoSQL injection. NoSQL databases may not have fixed schemas like SQL databases, but that doesn’t mean they’re any more resilient against injection attacks. In some cases, it makes exploitation even easier. We’ll show how ‘ OR ’1′ = ’1 still works wonders in the NoSQL space unless you’ve taken proper defensive measures.

Server-side JavaScript injection. The competition between Microsoft, Mozilla, Google and Apple to produce the fastest Web browser has given us incredibly fast JavaScript engines. (While I’m personally more than a little skeptical, some people are claiming that JavaScript outperforms C in certain benchmarks. But regardless of whether you believe this or not, you have to admit that JavaScript engines have come a long way in recent years.) Developers are taking advantage of the speed of these engines to create server-tier applications with them, notably Node.js Web servers and NoSQL databases. Now, when an attacker can inject his own script into a Web browser, we call that cross-site scripting, and we consider it one of the most serious Web application vulnerabilities there is (it’s currently #2 on the OWASP Top Ten list). But when an attacker can inject his own script into a server-side application, it’s even worse. Orders of magnitude worse. In some cases, these vulnerabilities can allow the attacker to upload and execute arbitrary binaries on the server – basically completely owning the machine.

Again, if any of this catches your interest, please stop by the OWASP LA meeting on Wednesday, April 27th. Hope to see you there! (If you’re interested but can’t make it, send me an email – brsulliv at adobe – and I’ll send you back the slides. If there’s enough interest, I’ll just post them here.)

Conference Update: CanSecWest 2011

Hi there!

Steve Adegbite here with an update on the Adobe security conference schedule.  Last month, Adobe’s security team was deeply involved with RSA Conference 2011. We had the opportunity to talk with many of you in our booth and at various sessions—customers, partners and other members of the security ecosystem.

This month, we turn our focus up north towards Vancouver, Canada, where yours truly, some of our security researchers (Kyle Randolph, Jim Hong and Peleus Uhley) as well as some folks from our product teams will be engaging with the security research community at CanSecWest 2011.

CanSecWest is one of the largest security conferences in the Pacific Northwest, and Adobe is proud to once again be a sponsor this year. Community engagement and event sponsorships are core aspects of our overall product security strategy and our commitment to doing whatever it takes to protect our customers. Members of the security community are our best allies when it comes to figuring out which initiatives to take on next as we all face a threat landscape that constantly changes.

This year at CanSecWest, we will be checking out the latest research on our technologies in hope of finding new ways to protect more customers. Our security researchers will be on hand for what looks to be a great three days of talks and community engagement. So if you are in the neighborhood, stop by and say “hi.”

Steve Adegbite – Senior Security Strategist

Advanced Persistent Buzzwords (Or: Yes, You Do Have to Outrun the Bear)

Hi all, Bryan here – I’m back home in snowy Seattle after a fun-filled week in San Francisco for RSA Conference 2011. One of my favorite games to play at RSA each year is to identify the hot buzzword or phrase of the year: the one meme that keeps popping up in every session and every vendor’s booth. The last few years have, of course, belonged to The Cloud, and this year looked like it was shaping up to be the year of the Advanced Persistent Threat. But then a dark horse came out of nowhere and snatched the buzzword crown away. The award for most overused expression for 2011 goes to The Bear – as in: You Don’t Have to Outrun the Bear.

I’m sure everyone reading this has heard the old joke about outrunning bears before, so I won’t tell it again here. Personally, I’ve never been a big fan of this philosophy. Basically, it suggests that you don’t have to aim for perfect security; you just have to be a little bit harder to attack than the other people around you. Now I know that security is not an absolute, that there’s no such thing as perfect security. But is “let them do it to the other guy” really the best we can strive for as an industry? It reminds me of the Far Side cartoon where (ironically) a bear is caught in a hunter’s crosshairs, and he’s grinning and pointing at his friend standing next to him. It’s especially worrying to me that this message seems to resonate so well with so many people.

Since we’re already talking about clichéd expressions, take a look at the Tragedy of the Commons, if you want to know where this line of thought will take us. Or better still, adopt a security philosophy that benefits the community, maybe “a rising tide lifts all ships.” This is the attitude that the most security-mature organizations take. Adobe benefits from platform defenses created by Microsoft and Apple. Microsoft and Apple likewise benefit from application defenses we build into our products, like the Adobe Reader sandbox. Even if you don’t work for an OS vendor, you can always contribute time to an open-source security project like the OWASP projects or simply share your knowledge by writing about what you’ve learned and helping others to avoid the same mistakes.

Ok, I’m getting off my soapbox now. I promise that next time I’ll be back with a less philosophical post that has some code snippets in it. But in the meantime, remember that it’s not enough just to run faster than your friend. If he’s falling behind, grab his arm, pull him to safety, and maybe both of you can live to tell about how you outran the bear.

Security is an industry concern and not one that is limited to a select group of vendors or products. No organization is immune to vulnerabilities and exploits. It is critical that vendors and the security community at large partner and work together to try and stay ahead of the game and combat those with malicious intent.

Java DoS Update

Happy Valentine’s Day, ASSET blog readers! Bryan here, and while I don’t have any roses or chocolate truffles for you, I do have something sweet for you if you’re still struggling with Java DoS issues. As I noted earlier, Oracle has released a patch tool here; however, if you’re not able to apply this fix for some reason, I have some new malicious value detection code courtesy of Brian Chess (of Fortify/HP) that is greatly improved over my original detection code. Many thanks to Brian and to Jim Manico from OWASP for passing this along.

private static BigDecimal bigBad;
private static BigDecimal smallBad;

static {
  BigDecimal one = new BigDecimal(1);
  BigDecimal two = new BigDecimal(2);
  BigDecimal tiny = one.divide(two.pow(1022));
  bigBad = tiny.subtract(one.divide(two.pow(1076)));   // 2^(-1022)  2^(-1076)
  smallBad = tiny.subtract(one.divide(two.pow(1075))); // 2^(-1022)  2^(-1075)
}

public static boolean containsMagicDoSNumber(String arg) {

  if (arg == null) return false;  // arg is null?  return.

  String noDot = arg.replace(".", "");

  // magic value not present?  return.
  if (!noDot.contains("2225073858507201")) return false;

  BigDecimal bd;
  try {
    bd = new BigDecimal(arg);
  } catch (NumberFormatException e) {
    return false;  // can't parse?  return.
  }

  // smaller than the smallest bad value,
  // or larger than the largest bad value?  Return
  if (bd.compareTo(smallBad) < 0 || bd.compareTo(bigBad) > 0) return false;

  // if you get here you know you're looking at a bad value.
  // The final value for any double in this range is supposed to be
  // 2.2250738585072014E-308
  return true;

}

Stop Exposing Yourself!

Hi everyone, Bryan here. My friend Ralph is a huge gadget lover. Whenever a new piece of electronic gadgetry comes out, Ralph has to have it. 1080p 3D HDTV and Blu-ray player? Check. Latest mobile phone? Check. Wireless network music player streaming from a RAID 5 NAS home media server? Check. So of course, when Ralph bought a new car, he had to get the GPS navigation system option. Now, GPS is a very cool and useful feature: You’ll always be able to find the fastest route home, or to the nearest gas station, or in Ralph’s case, to the nearest Best Buy. But consider the cost of that feature, not in terms of dollars and cents but rather in terms of attack surface. What would happen to Ralph, if someone stole that new car? The thief would not only have the car, but he’d have directions to Ralph’s house thanks to the GPS, and when he got there, he’d be able to let himself in with the automatic garage door opener.

There’s an obvious parallel here between cars and software. Consumers love features, consumers love convenience, and these things sell products. It’s our responsibility as security architects and developers to ensure that those features and convenience don’t add unnecessary attack surface. A classic example of this is the Microsoft Web server (Internet Information Services, or IIS for short) that’s included with Windows. In Windows 2000 and earlier, IIS was not only included as part of the operating system but also installed and activated by default. For those users who needed Web server functionality, this worked well and saved them some installation time. But the majority of Windows 2000 users probably never needed a Web server. My mother ran Windows 2000 on her home PC for a while, and I’d be surprised if she even knew what a Web server was! So when a vulnerability in IIS was discovered that allowed remote anonymous users to access private files, this vulnerability ended up affecting millions of users unnecessarily.

While this lesson has been learned (Microsoft still installs IIS with Windows, but you now have to manually enable it through the administrative Console Panel), I still see a lot of unnecessary attack surface present in SaaS applications. It may be easy to set allow-access-from domain=”*” in your crossdomain.xml file, but do you really need the extra attack surface that comes from allowing the entire Internet access to your resources? In products with wiki or blog features, it’s nice to allow users to use markup in their posts, but this one simple feature greatly complicates the difficulty of defending against cross-site scripting attacks. Or let’s say you’re developing a multitenant application: Simply adding a new “ClientID” column to your database tables instead of segregating your clients’ data into separate databases may lower hardware costs, but now you’re just one SQL injection vulnerability away from leaking all of their data.

I’ll be in San Francisco for RSA Conference next week to present “Stop Exposing Yourself: Principles of Attack Surface Analysis and Reduction” (session# AND-108, Tuesday 2/15 at 3:40 PM) along with Michael Howard from the Microsoft SDL team. We’ll be discussing these scenarios and many others, and Michael will be demonstrating their new Attack Surface Analyzer tool. If you’re attending the show, I hope to see you there!

Year of the Snail

Bryan here again. First I want to thank everyone who came out for my BlackHat DC talk on application-level denial-of-service attacks last month. I got a lot of great questions and feedback from all of you. Keep it coming! And just to throw more fuel on the DoS fire, there were at least two other sessions that focused on DoS: Tom Brennan and Ryan Barnett’s “Checkmate with Denial of Service” and Laurent Oudot’s “Inglourious Hackerds: Targeting Web Clients.” While today is supposed to start the Chinese Year of the Rabbit, it’s shaping up to be more like the year of the snail…

As if to prove the point, more research surfaced this week on the “magic number” DoS vulnerability I discussed in my Black Hat presentation and in my last blog post. Konstantin Preißer discovered that Java apps, similar to PHP apps, will fall into an infinite loop and hang trying to process numeric values in the (approximate) range of 2.2250738585072011E-208 to 2.2250738585072013E-208. For the case where you’re parsing a double value in from a string, you can apply this blacklist filtering code to detect whether the string value is potentially malicious:

public static boolean containsMagicDoSNumber(String s) {
return s.replace(".", "").contains("2225073858507201");
}

Note that the range of this check is wider than the actual values that will exploit the vulnerability, so you may end up with false positive results. I’ll keep this space updated with any news of a more thorough fix from Oracle.

Update: Oracle has released a Floating Point Updater Tool to patch the issue. Please be sure to read the associated readme file for the tool before installing, as there are important caveats.

Hey You, Get Off of My Cloud

Hi everyone, Bryan Sullivan here. Nope, this isn’t just a guest post: since November, I’ve officially been a part of the Adobe Secure Software Engineering Team and I’m very excited to be here! I’ll be working on (and blogging about) Adobe’s cloud service security engineering efforts, just like I did as a member of Microsoft’s SDL team. I’m looking forward to talking more about cloud security issues and maybe posting some code snippets in a language other than C# for once. :) In fact, we can start today with some PHP code.

 Earlier this week, Rick Regan, author of the Exploring Binary blog, discovered a flaw in PHP which causes PHP applications to go into an infinite loop when they attempt to process the numeric value 2.2250738585072011E-308. This one line of PHP code is enough for an attacker to be able to hang the application until it’s restarted:

<?php $number = (float) $_GET['number']; ?>

Denial of service (DoS) flaws like this one are referred to as application-level DoS vulnerabilities. The attacker doesn’t need to try to flood the target with malformed requests or use a botnet to create a distributed denial of service (DDoS) attack against the target; rather, he just exploits a hole in the application logic to throw the target into an infinite loop or an extremely long-running subroutine. Although it’s very serious and will probably end up affecting thousands of sites, the PHP flaw is just the latest of application-level DoS vulnerabilities. Other examples include zip bombs (files that decompress to sizes millions of times larger than their compressed forms), billion-laughs attacks (exponentially recursing entities in XML documents) and ReDoS (exponentially recursing regular expression evaluation strings).

The worst part about all of these techniques is that they’re both extremely effective at soaking up server resources and also extremely asymmetric in terms of attacker effort versus effect. In most cases, a single HTTP request of less than 1,000 bytes is enough to exploit the vulnerability. This essentially reduces the attacker’s cost to zero, makes it unlikely that he’ll ever be caught, and makes it even more unlikely that you’ll be able to prevent the attack with any kind of IPS or firewall. To defend against these attacks, you’ll have to make changes to your application code. (As a side note for the curious and/or terrified, the two most commonly suggested mitigations for the PHP issue are either to recompile the PHP processor itself with the -ffloat-store compiler option or to add input validation to check incoming requests for the malicious value.)

I’ll be giving a presentation at Black Hat DC later this month, titled “Hey You, Get Off of My Cloud: Denial of Service in the *aaS Era“, that takes an in-depth look at application-level DoS attacks and specifically their impact on cloud applications. With elastic computing resources, there’s less of an issue with DoS causing outages, where legitimate users can’t get access to the site, but you trade that off for a potentially bigger “economic denial-of-sustainability” issue. Since you’re paying for your cloud resources on a per-cycle/per-gigabyte/per-megabit basis, a DoS attack could very quickly overcome your budget and force you to take the site down yourself. For the attackers, this has an added bonus in that they can provide you with metrics when they deliver their blackmail demands. “Give us $25,000 or we’ll take down your site” is bad enough, but “Give us $25,000 or we’ll soak up $50,000 worth of cloud resources” is worse still.

I do look forward to seeing you in Washington, DC in a few weeks and to discussing this surprisingly under-appreciated problem in more depth. And if you can’t make it out but still want to learn more, please feel free to email me: My Adobe email alias is brsulliv. Thanks, and we’ll talk again soon!