What exactly is micropatching?
Patching even though there actually are no more patches
Security solutions like to disguise in fancy new terms. Maybe you’ve come across the term “micropatching” lately? Claudius Manthey and I have briefly summarized what it is all about.
Why does micropatching exist?
Micropatching is intended to solve two common patching problems:
- A software manufacturer takes too long to provide security patches.
- A software manufacturer does not provide security patches at all (anymore)
A classic: end-of-life operating systems like Windows 7 or Windows XP.
Why is it called micropatching?
Important to note: Micropatching provides small patches that do not come from the manufacturer and only patch individual, selected security vulnerabilities (hence the “micro”). Because suchlike patches need to be crafted in a laborious process (we’ll learn why in a minute), the focus for micropatching is mostly on frequently installed systems and particularly critical vulnerabilities.
The maybe best-known company for micropatches is the small Slovenian provider Acros Security with its solution “0patch”.
How does it work technically?
If you want to patch but you are not the manufacturer of the software, you have two obstacles to overcome:
- The new executable must be accepted by the target system, but it is not able to use the manufacturer’s signatures.
Traditional patching replaces the executable files (usually *.exe, *.dll, *.ocx or similar) on the hard disk with new executable files. Both the old and the new files are compiled from source code by the vendor and then signed by the vendor.
However, since micropatches come from third-party vendors, they of course have no access to the source code or the manufacturer’s private keys and therefore cannot follow this usual route. Instead, it needs to perform a deception maneuver where timing is key: each time the executable is loaded into main memory, an automatic agent loads the file to be patched after the signature is verified, but before the binary code is executed.
- The micropatch must modify the executable in a targeted manner without knowing the software manufacturer’s source code.
The micropatch must, of course, contain changes from the original code, after all patching is all about updating and thus modifying the binary code that is executed.
Again, without knowledge of the source code, a third-party vendor does not have the option to use the usual route — changing the source code, compiling it, and replacing the file that is executed. Instead, they need to derive the necessary changes from analysis of changes made to newer versions of the program, or develop them entirely on their own, e.g., by reverse engineering.
Example: If some bytes have changed in Office 2016 due to a patch, micropatch providers try to see if this change also works in the no longer supported Office 2010.
Where are problems?
The core problem is that a micropatch must get a system to accept a change in software that has not been approved by the manufacturer.
Sounds familiar? It is. After all, malware has the same goal, which is why the first technical question is what anti-malware solutions, which are supposed to prevent exactly this, react to micropatching.
Moreover, micropatching means that you put a lot of trust in the provider of the micropatch (and its suppliers, and its security concept). You are allowing a third party company to make unverifiable changes to another manufacturer’s code, in the hope that they will understand all the implications and side-effects.
Is micropatching a viable option in industrial IT (OT)?
In short: Rather not. There are four reasons beyond the problems above:
- Manufacturer approvals and liability
Especially in OT, manufacturers are extremely meticulous about approving system changes. Making system changes that were not explicitly approved can quickly void product liabilities— even for “official” patches from the original software manufacturer. Micropatches, being “non-official” patches, are even more unlikely to be accepted.
- Product coverage
Micropatching is (currently) focused on very popular IT software used in many areas — often these are Microsoft products. Many products used in OT are likely to fall through the cracks for the time being.
- Internet connection of the micropatching agent
Micropatching usually requires an agent with internet connectivity to be installed on the target system. This means that you increase the attack surface for many OT systems that do not have an internet connection.
In principle, the same is true for conventional patching, but for OT, offline or semi-offline options exist: a local patching server with temporary internet connection or even manual patching are still common.
- Lower-risk alternatives
For many products that are covered by micropatching, the manufacturer does still provide updates — for an additional fee. And: In OT, “informed non-patching” is definitely an option — the very static OT systems can sometimes be protected more sensibly in other ways, for example through segmentation and strict access regulations.
This article was also published in the monthly “Security Briefing for Hard Hats” (in German).