Patch/Configuration Management, Vulnerability Management



For, by Chris Andrews, vice president of security technologies, PatchLink Corp.

The only way to truly eradicate a threat is to deploy a fix or policy change across all systems. Hence, the emergence of third-party fixes that give users more options to mitigate their network security risks.

While it is true to say that rogue patches pose a significant threat to a network — potentially causing systems to fall over — a third-party fix rigorously tested, scrutinized, code reviewed and endorsed by reputable security organizations is a different ball game.  

The decision to implement a third-party patch also depends on if the vulnerability is policy-based and easy to temporarily work around until a fix is made available by the vendor. For a vulnerability that is more complex and poses a high security risk, such as the WMF vulnerability which required uninstalling an application, it becomes more important to deploy an endorsed security fix. Yet only a small proportion of organizations (13 percent) deployed the WMF third-party fix, while the majority of administrators rallied for Microsoft to break its patch cycle.

Against, by Amol Sarwate, vulnerability research lab manager, Qualys.

In January 2006, a Russian programmer, Ilfak Guilfanov, released a third-party patch to fix Microsoft’s WMF vulnerability 11 days before Microsoft’s official fix.

Third-party patches from individuals are not uncommon, but this was the first time security companies released their own patches. Microsoft advised users to wait for the official fix. The latest CreateTextRange Microsoft browser bug allows malicious hackers to take over PCs that were used to visit specially crafted pages. These types of security issues compel customers to use a stop-gap arrangement.

While Guilfanov’s patch may have worked as intended, typical non-vendor patches do not undergo intense testing, may not work in all environments, and come with no guarantees.

Potential risks of third-party patches far outweigh their benefits. Affected companies should investigate possible workarounds and alternatives rather than laying themselves open to the damage caused by a corrupt patch.

Bottom line: "Proceed with caution."


What is it?

A DNS amplification attack uses recursive DNS servers to overwhelm a target IP address with a flood of DNS traffic. The effect is similar to other denial-of-service (DoS) attacks.


How does it work?

The domain name system relies on a lookup method known as recursion, where a nameserver will perform a DNS query on behalf of another machine, caching the answer for later retrieval by other clients. In the amplification attack scenario, a server configured to allow recursive requests from anywhere is sent a query for a domain name under the attacker’s control. The attacker provides a reply with a large number of records, which is cached by the recursive server. Now the attacker sends further queries for the domain name, this time spoofing the source address of the intended victim, who receives the cached reply.

Should I be worried?

The risk is no greater than conventional distributed DoS attacks. It is more likely that you could become an unwitting party to such an attack rather than a target of one. You should take measures to prevent your DNS servers from being abused in this manner.

How can I prevent it?

Check the configuration of any internet-facing DNS servers for your domain and ensure that they do not allow recursive queries from hosts outside your network.

Joe Stewart, senior security researcher, LURHQ

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.