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!