The rise of zero-day patches

The experts speak

Internet Security Threat Report 2014

Part 2: ZERT

What is ZERT?

ZERT: ZERT (the Zero-day Emergency Response Team) is a group of engineers with extensive experience in reverse engineering software, firmware and hardware coupled with liaisons from industry, community and incident response groups. While ZERT works with several Internet security operations and has liaisons to anti-virus and network operations communities, ZERT is not affiliated with a particular vendor. The purpose of ZERT is not to "crack" products, but rather to "uncrack" them by averting security vulnerabilities in them before they can be widely exploited.

Why do we need a Zero-day Emergency Response Team?

ZERT: In recent times there has been significantly more effort by criminal elements to exploit zero-day vulnerabilities for financial gain. In some cases the pervasiveness of vulnerabilities presents a critical risk to a significant number of internet users. At such time it may be desirable to some people to have an option to implement interim safeguards until a manufacturer's patch is available. ZERT members work together as a team to release a non-vendor patch when a so-called "0day" (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the internet, or both.

What type of channels do you control to look for zero-day exploits?

ZERT: ZERT members belong to and work with a wide variety of organisations that encounter zero-day exploits or reports thereof.

At the moment you have released some patches for Microsoft software. Do you plan to work on other vendors' software too?

ZERT: When a zero-day is announced members of ZERT will discuss the perceived exploitability of the vulnerability and the anticipated impact. If the vulnerability is deemed to be critical enough to warrant a patch and the members have the time and skills to create a patch that they are comfortable with then the name of the vendor is not really a concern.

How much time do you need to develop a patch? How much additional effort is need to support localised versions of the software?

ZERT: The amount of time to develop, test and release a patch will vary from vulnerability to vulnerability. There really haven't been enough patches released by ZERT to have a meaningful historical reference. To date we have not discussed the localisation of patches.

Generally closed-source vendors take a long time to release patches. They often claim that this time is required to test all possible configurations and interactions with other software to avoid breaking production systems. How can your approach be faster even without access to source code? What type of reliability testing do you make?

ZERT: ZERT always recommends that anyone using a third party patch perform extensive testing in their environment to determine the suitability and compatibility of the patch. ZERT cannot perform the in-depth testing that we would expect of the vendor. If a person is faced with taking one or more servers or workstations offline or trying a third party patch until the vendor has an authorized solution, the choice may be to risk a patch that has undergone less than optimal testing. Generally, if vendor supplied workarounds are viable those would be a first choice.

ZERT developers and beta testers test the patches on a variety of systems, but we do not claim to be able to perform the exhaustive testing that a vendor would. That is why ZERT always recommends caution in the use of third party patches and proper testing in the user's environment.

Did you have any legal problem posting some disassembled code from a Microsoft patch in your paper [PDF]?

ZERT: No, we have not had any legal problems at all.

ZERT has a legal advisor, but we have not had legal issues at all, other than how we wish to license our patches. ZERT does not publish vulnerabilities, ZERT provides patches for published vulnerabilities.

From your analysis of official patches from Microsoft, what can you say? What approach do they use when fixing bugs?

ZERT: ZERT has no interest in the variety of ways that a vendor may choose to approach the problems they solve. Vendors must choose the methods they deem most suitable on a case by case basis. ZERT's focus is generally on interim solutions for critical vulnerabilities.

How do you install your patches? Do you need to include some pieces of the file you are going to patch? Do you think this could become a legal problem?

ZERT: There are a variety of ways to patch vulnerabilities. Care is taken not to redistribute code in a manner that would violate license agreements. We have had no reason to expect any legal problems to date and do not expect any in the future. We license our software as open source under BSD or GPL.

Will new Vista security mechanisms block the use of external patches?

ZERT: This will depend on what needs to be patched. As long as it is not the kernel or a signed driver it is unlikely to have much effect on third party patches, and probably virtually no effect on patching vulnerabilities for other vendor's products.

Does Microsoft EULA limit your power to develop and/or distribute fixes?

ZERT: Microsoft EULAs do not apply to Linux, Apple, Sun, Dlink, Linksys, etc. ZERT is not a vendor centric organisation. We have not had any issues with Microsoft in regards to EULA infringements.

Are you aware of any new clause included in Windows Vista EULA that could affect your work?

ZERT: ZERT enjoys open communications with Microsoft. If a Microsoft EULA is ever an issue with respect to a ZERT patch we are confident that Microsoft will advise us of an concerns. We do not anticipate any issues with any vendor's EULAs however.

Federico Biancuzzi is freelancer. In addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.

This article originally appeared in Security Focus.

Copyright © 2007, SecurityFocus

Secure remote control for conventional and virtual desktops


Designing and building an open ITOA architecture
Learn about a new IT data taxonomy defined by the four data sources of IT visibility: wire, machine, agent, and synthetic data sets.
5 critical considerations for enterprise cloud backup
Key considerations when evaluating cloud backup solutions to ensure adequate protection security and availability of enterprise data.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Protecting against web application threats using SSL
SSL encryption can protect server‐to‐server communications, client devices, cloud resources, and other endpoints in order to help prevent the risk of data loss and losing customer trust.