Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

4/2/2019
02:00 PM
Paul Makowski
Paul Makowski
Commentary
100%
0%

War on Zero-Days: 4 Lessons from Recent Google & Microsoft Vulns

When selecting targets, attackers often consider total cost of 'pwnership' -- the expected cost of an operation versus the likelihood of success. Defenders need to follow a similar strategy.

Recently, two in-the-wild exploits for zero-day vulnerabilities in Google Chrome and Microsoft Windows were disclosed by Google's TAG (Threat Analysis Group). The event made headlines, but it's not a new story: a zero-day vulnerability under active attack is discovered, vendors scramble to issue patches and companies scramble to deploy these patches. Substantial cost is incurred each step of the way. (For reference, Google patched the Chrome zero-day [CVE-2019-5786] and Microsoft patched the Windows 7 zero-day [CVE-2019-0808].)

The bad news is we've been doing this dance for decades. The good news is that some pockets of the industry have invested significant time and energy into reducing the impact and frequency of attacks that leverage zero-day vulnerabilities. In fact, Google and Microsoft are among the leaders in this space.

What can software companies that lack the security budget of tech titans learn from this latest event, and what can IT managers/CISOs/enterprise decision makers learn to inform product decisions? Here are four strategies to consider:

Software Developers: Adopt a Healthy Skepticism of Unsafe Languages
Unsafe languages (C, C++, Objective-C) are unsafe. There are various definitions of safe, of course, but the C language family doesn't qualify for any of them. Treat unsafety for what it is: cost, risk and liability. Consider Rust or Go among a range of alternatives.

On the surface, it may appear cheaper to develop in a language that's perhaps more familiar, but you need to consider the total cost of ownership (TCO) of that choice. If you want to use an unsafe language to build a safe product, you'll need to invest in exhaustive unit tests, handle any current and future undefined behavior, accommodate cross platform differences, and maintain a fuzzing suite — at a minimum. Like Google and Microsoft, you'll need processes in place for when all these things fail to identify an issue — and they will.

If you're starting a new project, there are very few compelling reasons to build in an unsafe language. Reasons typically given include:

  • Project performance is critical and even minimal overhead is unacceptable,
  • Platform does not support a safe language, and the
  • Project will never handle untrustworthy input.

The cost gap of the first two is closing daily and the last is undecidable. It's unlikely, for example, that the developers of Ghostscript anticipated untrustworthy input via thumbnail processes in Gnome.

If you're maintaining an existing unsafe-language project, consider piecemeal conversion of that codebase to a safe language. Mozilla has been doing that with Firefox, that is rewriting various unsafe language portions of the browser in Rust.

Enterprises: Don't Use Outdated (Even if Supported) Operating Systems
What does it cost to upgrade your enterprise from Windows 7 to Windows 10? This can be difficult to quantify. What is perhaps even more difficult to quantify is the value gained from a modern operating system — but both are equally important for calculating an accurate TCO.

The aforementioned zero-day exploit in Windows made use of a null pointer dereference vulnerability in win32k.sys. This class of vulnerability is not exploitable on Windows 8+ and Windows 10 provides additional controls to app developers that substantially reduce the attack surface of this module. Continuing to run an outdated operating system comes with security cost.

You can't patch your way to security, yet patches are typically all you get with an outdated operating system. Windows isn't alone; macOS and Linux deploy new and fix existing exploitation mitigations with each release. By using outdated software, you don't reap these benefits.

Software Engineers: Know Your Attack Surface
Zero-day vulnerabilities in widely deployed software are worth money — sometimes a substantial amount of money. Gone are the days when security researchers disclosed zero-day on infosec conference attendees. The meat of many presentations at today's offensive-oriented conferences is exploration of previously unknown, unexplored attack surfaces in commodity software.

You need to identify all the ways your product might interact with untrustworthy input — your attack surface. Intended use cases are the tip of the iceberg. Some of the best value you could get out of a third-party audit is to learn new ways of interacting with your software.

Software Developers: Identify, Track, and Sandbox Untrustworthy Input
Once you've mapped out your attack surface, track and contain the usage of that untrustworthy input — and consider sandboxing the code responsible for handling it. The Chromium developers (including Google) have done an excellent job of describing Chrome (Chromium's) sandbox design. Use this as inspiration: directly build on it (the code is very liberally licensed) or use Google's just-released Sandbox API. Adobe built on Chromium's sandbox almost a decade ago, reducing the impact of PDF parsing vulnerabilities in Adobe Reader. If in doubt, consult Chromium's Rule of 2.

Both: If You Must Run/Develop Unsafe-Language Code, Use Exploit Mitigations
If your software product is locked into an unsafe language, there is no excuse to not leverage exploit mitigations offered by your compiler and target operating system.

Valve's Steam (think iTunes for games) contained multiple vulnerabilities that attackers leveraged to install malware on players' machines. In a separate report, Steam was vulnerable to a classic stack-based buffer overflow in the way it parsed game information. Exploitation was made simple by lack of stack protection, a protection available in various forms for over a decade. Don't be like Valve.

Exploit mitigations are no substitute for choosing to develop in a safe programming language. If you must maintain or develop in an unsafe language, enable them as a matter of course, but do not rely on them as a reason to delay moving to a safe language. If you're responsible for deploying software, use the exploit mitigations available to you.

When selecting targets, attackers often consider total cost of "pwnership" — the expected cost of an operation versus the likelihood of success (times expected value) As a defender or a software engineer, conduct the same analysis — and consider the way your choices affect the security of software development and deployment.

Related Content:

 

 

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Paul Makowski's interests include exploitation, program analysis, vulnerability research, reverse engineering and cryptography. Prior to co-founding PolySwarm, Paul reverse engineered implants and wrote bespoke malware disinfection tools for Fortune 100 clients. Paul ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
PaulChau
50%
50%
PaulChau,
User Rank: Apprentice
4/12/2019 | 1:19:09 AM
Prevent from the start
In today's highly digitized era, victims have to stay smart and beat cyber attackers at their own game. It is critical to learn of potential risks and stop them before they can even happen. The more high-tech we become, the more advanced hackers get which means we need to stay alert.
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12888
PUBLISHED: 2019-06-26
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2019-12887. Reason: This candidate is a reservation duplicate of CVE-2019-12887. Notes: All CVE users should reference CVE-2019-12887 instead of this candidate. All references and descriptions in this candidate have been removed to preve...
CVE-2019-12280
PUBLISHED: 2019-06-25
PC-Doctor Toolbox before 7.3 has an Uncontrolled Search Path Element.
CVE-2019-3961
PUBLISHED: 2019-06-25
Nessus versions 8.4.0 and earlier were found to contain a reflected XSS vulnerability due to improper validation of user-supplied input. An unauthenticated, remote attacker could potentially exploit this vulnerability via a specially crafted request to execute arbitrary script code in a users browse...
CVE-2019-9836
PUBLISHED: 2019-06-25
Secure Encrypted Virtualization (SEV) on Advanced Micro Devices (AMD) Platform Security Processor (PSP; aka AMD Secure Processor or AMD-SP) 0.17 build 11 and earlier has an insecure cryptographic implementation.
CVE-2019-6328
PUBLISHED: 2019-06-25
HP Support Assistant 8.7.50 and earlier allows a user to gain system privilege and allows unauthorized modification of directories or files. Note: A different vulnerability than CVE-2019-6329.