Patching

patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it. This includes fixing security vulnerabilities and other bugs, with such patches usually being called bugfixes or bug fixes. Patches are often written to improve the functionality, usability, or performance of a program.

Patches may be installed either under programmed control or by a human programmer using an editing tool or a debugger. They may be applied to program files on a storage device, or in Computer memory. Patches may be permanent (until patched again) or temporary.

Patching makes possible the modification of compiled and machine language object programs when the source code is unavailable. This demands a thorough understanding of the inner workings of the object code by the person creating the patch, which is difficult without close study of the source code. Someone unfamiliar with the program being patched may install a patch using a patch utility created by another person who is the Admin. Even when the source code is available, patching makes possible the installation of small changes to the object program without the need to recompile or reassemble. For minor changes to software, it is often easier and more economical to distribute patches to users rather than redistributing a newly recompiled or reassembled program.

Every day, millions of web sites and emails contain links to malware known as “exploit kits.” Malicious programmers (or programming teams) create exploit kits and then use them or sell them. An exploit kit usually contains everything a wannabe hacker can need in the exploit cycle, including 247 technical support and auto-updating to avoid getting caught by antivirus scanners.
A good exploit kit will even find and maliciously modify otherwise innocent web sites to ensure it gets executed whenever visitors browse to the infected web site. All the attacker has to do is buy the kit, execute it, and send it along its way to find victim web sites. Exploit kits almost always contains client-side (programs that run on end-user desktops versus code meant to exploit servers) exploitation routines that check for multiple missing patches.They can check for anywhere from a handful of vulnerabilities to several dozen. Any unpatched , unlucky visitor gets silently exploited (by what is also known as a “drive-by download” attack), whereas fully patched web surfers usually get prompted by a social engineering trick to install a Trojan horse program. Exploit kit bad guys would rather exploit unpatched devices than use social engineering because not all end-users will automatically agree to install any program they are prompted to install. The involved vulnerabilities are routinely updated so that the exploit kit can be as successful as possible. Most exploit kits even contain centralized management consoles so the criminals can check to see what vulnerabilities are working and how devices are infected. Even without exploit kits being involved, missing security patches are one of the biggest problems that allow successful exploitation. This may change one day, but so far this fact has been true for more than three decades. To give yourself or your computers the best protection against software vulnerability exploitation, all you have to do is apply security patches in a timely and consistent manner. That sounds easy enough to do. There are even dozens of tools that can help you. Unfortunately, effective patching remains overly difficult and elusive. In my entire career, scanning hundreds and hundreds of thousands of computers for patching, I don’t think I’ve ever found a fully patched computer. If I have, I can’t remember it. It’s that rare.

Common Patching Problems
If patching were easy, it wouldn’t still be the big problem that it is today. The following sections describe some of the issues involved with patching.

Detecting Missing Patching Isn’t Accurate
No matter what program you run to check for missing patches, it will miss some percentage of devices. It’s not always the patch management program’s fault. Computer devices are complex machines with lots of moving, buggy parts, and any of those buggy parts can stop accurate patch checking. On top of that, users may use devices or versions that aren’t supported by your patch-checking program, or your network security boundaries might be in the way. There are many more reasons why patch-checking status may not be accurate, but it suffices to say that they are never 100% accurate. And if you can’t detect it, you can’t patch it.

You Can’t Always Patch
Sun (and now Oracle) Java has long been one of the most exploited programs when left unpatched, and unfortunately most of the world left it unpatched for nearly two decades. Java programmers consistently write their programs (incorrectly) to rely on particular Java versions and features, and updating Java could break programs relying on a particular version. For that reason, most enterprises knew they had a high percentage of unpatched Java programs and that Java was the biggest reason for successful exploits in their enterprises, but they still were not able to patch Java. It turns out that causing operational interruptions will get you fired far more quickly than simply reporting that you can’t patch something because the business owner won’t let you.

Some Percentage of Patching Always Fails
As with checking for missing patches and for the same reasons, some small percentage of computers will never get the patch applied that you told them to apply. In my experience, that number of devices is around 1–2% on average, but sometimes it jumps way higher to something like 15–20%, depending on the complexity of the patch and the involved devices. One great way to defeat patching issues is to follow up and try to resolve the issues on computers that have poor patch detection and application rates.

Patching Will Cause Operational Issues
Vendors try their best to reduce the number of operational issues caused by a particular patch, but they cannot be expected to test their patch on every unique combination of hardware and software that the patch might be applied to. Sometimes applying a very reliable and safe patch can be undone by previously undetected malware or an untested third-party program. Most companies have been burned by one or more patches causing a significant operational interruption, and they are hesitant to apply future patches without lots of testing (which they often don’t have the time or resources to do). Because of the fear of unintended operational issues, they either don’t ever apply the patch or don’t apply it in a timely manner. I understand the fear, but the risk of not applying critical security patches in a timely manner is higher than the possible, less likely operational issues. If you are worried about operational issues, just wait a few days. Most of the time the serious operational issues are found by other faster adopters and resolved by the vendor so you can safely apply the patch.

A Patch Is a Globally Broadcasted Exploit
Announcement

When a patch is released to close a security vulnerability, if it wasn’t already publicly known, it is now. Malware writers and exploit kit programmers will quickly examine any patch that comes out and reverse engineer it to find out how to exploit the now-solved vulnerability. Because it takes the best patchers a few days to patch and some people never patch, every newly released patch is another likely avenue for exploitation. Some vendors sneak high-criticality bug fixes into patches that address other issues and do not announce the bug. Later, they formally announce the vulnerability and provide an official patch. By that time, thanks to the earlier patch, the bug has already been fixed across a majority of computers. One very popular OS vendor once deployed a critical patch fix over several months of patches. To the reverse engineers, it looked like unexplained garbage code segments, but once three months of patches had been applied, the whole buy fix was applied to close the huge hole, leaving happy (and mostly unaware) customers and frustrated hackers. In the end, good patch management means one thing: timely, consistent patching of the most likely to be exploited programs. It’s easy to say but hard to do. My advice is to turn on all automated patching or use a reputable patch management program that can handle all your software patching needs (and hardware too, if possible) and let critical security patches be applied within a few days. If you patch within a few days, you’ll be among the most protected environments on the Internet. Perfect patching may not be easy, but patching the critical vulnerabilities of the most likely to be exploited programs is essential on any computer. Not doing so is effectively just asking to be exploited

No comments

Powered by Blogger.