Archive for February, 2011

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.