DeepSec 2016 Workshop: Do-It-Yourself Patching: Writing Your Own Micropatch – Mitja Kolsek

Sanna/ October 13, 2016/ Conference, Development, Security, Training

The current state of updating software – be it operating systems, applications or appliances – is arguably much better than it was a decade ago, but apparently not nearly good enough to keep even the most critical systems patched in a timely manner – or at all, says Mitja Kolsek.

Official vendor updates are cumbersome, costly to apply, even more costly to revert and prone to breaking things as they replace entire chunks of a product. Enterprises are therefore left with extensive and expensive testing of such updates before they dare to apply them in production, which gives attackers an endless supply of “n-day” vulnerabilities with published exploit code.

Furthermore, for various entirely rational reasons, many organizations are using products with no security updates such as old Java runtimes, Windows XP, or expensive industry systems that still work perfectly well but are not supported any more by their vendor.

Fortunately, there is a better way to approach vulnerability patching, one that not just minimizes the risk, hassle and costs, but also allows 3rd parties with no access to source code to write a patch. It’s called micropatching and it injects or replaces tiny fractions of machine code within the memory of a running process to patch a vulnerability. (Or, why not, a functional defect in your unsupported application.) Sounds interesting! We asked Mitja for more information about his workshop.

Please tell us the top 5 facts about your workshop.

• This is the first workshop in the history of computing that will teach people to write efficient, reliable patches for someone else’s closed-source code.
• Using this knowledge, one can fix vulnerabilities that original vendors refuse to fix, or fix functional problems in unsupported product versions, which vendors would prefer to have fixed by selling an expensive new version.
• Attendees will take apart a couple of widely-used software products, analyze vulnerabilities in them and create patches that will block proof-of-concept exploits. We will then rejoice over contributing to a more secure future while turning our patches on and off without relaunching the applications.
• Attendees will make their first big steps towards becoming fully qualified code doctors, allowing them to fix functional or security issues on both their own or corporate computers, as well as to start a career as “bug fixers”, paying their bills and mortgages by fixing bugs for millions of other users.
• In case it wasn’t obvious: Our plan is to equip security researchers and IT enthusiasts with tools and knowledge for actively fixing the growing problem of vulnerable and buggy closed-source code and code that needs fixing without restarting millions of computers or blocking millions of transactions.

How did you come up with it? Was there something like an initial spark that set your mind on creating this workshop?

Our team has been (legally) breaking into customers’ networks for over 15 years and we’re thoroughly disappointed that it is just as easy to break in today as it was when we began. It is easy and inexpensive to find an exploit for a vulnerability in a browser, reader or text editor these days that might have been patched by its vendor, but almost certainly hasn’t been applied in a big network yet. So this “security update gap”, as we call it, combined with a huge number of vulnerabilities that do not, and never will have official fixes, makes attacker’s job ever easier.

We wanted to turn the tables by “fixing the fixing” – finally bringing the way we’re patching vulnerabilities up to this century. So we’re building a micro-hot-patching platform that will enable any security enthusiast with some knowledge of reverse engineering and machine coding to fix a piece of code, even without access to its source code. This will take the “monopoly on fixing” from software vendors, and provide a foundation for a crowdpatching community, where security researchers will not only find bugs, but also fix them and get financially rewarded for it by those whose problems they actually solve: software users.

Why do you think this is an important topic?

Obviously, software fixing is not going to fix itself. It took a tremendous community effort and a lot of time to push at least the biggest software vendors, and at least for their supported software, from “occasional opportunistic updates” to “huge regular updates that often break stuff, require restarts, and are a pain to revert.” And this is about as far as vendors can be pushed, because now they can claim to be diligent and prompt in providing bug fixes, while it’s users’ fault if they’re not applying these fixes in a timely fashion. We need a different strategy for pushing things further towards actually fixing bugs (as opposed to just making fixes available), and we believe that micropatching is the most efficient solution as it minimizes the risk of functional problems, makes patches easy to review, requires no downtime for applying or removing patches – but most importantly, allows 3rd parties to fix bugs that were previously at the sole mercy of vendors’ business priorities.

Is there something you want everybody to know about your your training?

Prepare to be dazzled – we’ve been doing this for over two years now but it still feels magical to witness a vulnerability getting patched, or unpatched, in a fraction of a second while the application is running. You’ll experience this on your own computer with a patch you write and compile yourself, and you will want to show it to everyone you meet (which might result in some awkward situations with strangers on the street outside the conference hotel).

A prediction for the future – what do you think will be the next innovations or future downfalls when it comes to particularly your field of expertise / the topic of your workshop?

There’s still a long way to go before every computer, phone, deep space probe, car and IoT device down to the last smart toothpick supports micropatching, and a lot of obstacles to overcome, but the course is set and unless we want to stay in this ever-warmer patching hell we’re in now, we’d better start digging a way out. The growing availability of micropatching will lead to new research on automated micropatch generation and testing, including formal verification of patch correctness. Coupled with advances in automated vulnerability detection, we’re heading towards building a powerful global automated “IT immune system,” which will make attacks against code ridiculously expensive and a wasteful of effort. And then we’ll patch us, people – but that’s not until next year’s DeepSec workshop.

This years two-day workshop will teach you how to create a 3rd party “unofficial” micropatch for various known vulnerabilities in popular Windows software. We will start with a proof-of-concept document that triggers a vulnerability, determine the type of vulnerability (buffer overflow, use-after-free, format string…), find its root cause, and finally create a micropatch for it, which we’ll apply using the 0patch Agent.

You will learn how to approach patching of different types of security flaws, how to find a suitable patching location, and how to test a micropatch.

Attendees should have experience with reading assembly language (ideally also reverse engineering) and have their own Windows laptops with the following software installed:

• Microsoft WinDbg 32bit version x.y.z (to be defined before the workshop)
• Adobe Reader DC version x.y.z (to be defined before the workshop)
• Foxit Reader version x.y.z (to be defined before the workshop)
• 0patch Agent for Windows version x.y.z (to be defined before the workshop)
• 0patch Factory version x.y.z (to be defined before the workshop)

But also do come if you happen to have a nasty functional defect in your expensive custom application that would cost you an arm and leg to update.

This workshop is suitable for security researchers, who will learn how to write micropatches for vulnerabilities they find, as well as for software vendors, who want to avoid the costly process of rebuilding, retesting and redeploying their product every time someone finds a vulnerability in it that could be fixed with a few machine instructions.

Mitja’s last 15 years of career comprises co-leading a small security outfit which ran APT-like attack simulations before China was guilty of everything, using SQL injection before it had a name, and discovering vulnerability types which were previously unknown. In addition to finding and exploiting vulnerabilities, his next 15 years will be augmented by fixing them. Most of all he’d like to leave information security some day in a state where it’ll be seriously difficult to break into a typical network deploying standard and inexpensive security solutions.