I've been thinking about the problems that occur when a new vulnerability appears, and how vendors and users react in these situations.
In cases where a vulnerability is found in a specific program, the vendor is responsible for finding a fix and distributing the patched versions to users.
In cases where a vulnerability is found in a module (a system DLL or third party module), many programs may be affected, but the approach is the same - the vendor has to distribute the patched module to the users.
There is a dreaded third case, when a vulnerability is found in a third party's LIB and has been embedded in programs and/or modules. In order to eliminate this type of vulnerability from the wild, it's necessary to recompile all the programs/modules affected. Then, the vendor of each affected application has to distribute its patched versions.
This process generally doesn't happen overnight. In fact, it can be extremely complicated and time-consuming. But from the time the vulnerability is found to the moment users download the patched version, they are at risk. That's a problem.
The Workaround Concept
In security, a workaround is a temporary fix used to prevent attacks. Usually, it's implemented in cases when an official patch has not yet been published.
For example, consider a vulnerable application that can be exploited by sending crafted packets to the TCP port 44444. As a workaround, the user could block this port through a firewall. The user is able to avoid attack, but the application loses functionality because no TCP packets will be processed at this port. Workarounds can also be executed from the Windows registry, where the user can disable some system functionalities.
Sometimes, the official patch exists, but the computer can't be turned off and the server administrator has to wait for a specific amount of time time before installing the new software.
And sometimes, a user cant do anything to prevent attack, because no workaround was published or the workaround just doesn't exist.
In this case, we could consider:
- Install a third party fix
- Install an exploit mitigation tool
- Turn off the computer
The second option is a generic solution, but it can't always be used (e.g. kernel bugs), it could be bypassed and it doesn't fix the source of the problem, the vulnerability itself.
A month ago, an Embarcadero's advisory was published: Delphi and C++ Builder VCL library Buffer Overflow
According to the Embarcadero's advisory, a fix was introduced in line 4775:
if ColorCount > 256 then
Essentially, the "PaletteFromDIBColorTable" function could be exploited by sending a 'BITMAPINFOHEADER.biClrUsed' (ColorCount var) value greater than 256.
Looking at this picture, we can see a part of the "ReadDIB" function and the route to exploit this bug.
Then, the function where the stack overflow was done:
The problem here is that the fix was badly implemented, and the checking was introduced in a wrong place. This was a partial fix - it eliminated one path to exploitation - but it did not address the source of the problem.
Now, there is a new Embarcadero’s advisory.
As was the case in the previous advisory, we explained that this vulnerability could be exploited by setting a value greater than 256 to the 'BITMAPINFOHEADER.biClrUsed' var. In our second advisory, we demonstrated how this could be done in the "ReadDIB" function.
Below we can see another part of the "ReadDIB" function, and the route to exploit this new bug, a heap overflow.
If the patch is available, the vendors are forced to recompile their products again, and it forces the users to download new versions of the software.
The question is, if I don't have the source code and to fix this vulnerability you only need to add an "IF" in the code where the 'BITMAPINFOHEADER.biClrUsed' var is set for the first time, as an affected user, should I waiting for all affected vendors to repeat the same fixing, recompiling and distributing process to protect my computer from exploit attacks?
Workaround for "Embarcadero VCL library"
At the moment, you can download a TOOL that allows you to fix this vulnerability in runtime and prevent possible attacks against applications compiled with the "VCL Library" written by Embarcadero (until the official patch appears for each affected application).
Essentially, this hot-fixer introduces (in runtime) an "IF" in the active programs where the vulnerable lib was included. The only restriction is that the affected code has to be in the main executable, not in DLLs.
What does the introduced patch check? When a crafted ".BMP" file is being opened, if this new code detects that the 'BITMAPINFOHEADER.biClrUsed' variable is greater than 256, a warning message appears and the program is closed. This avoids any possible exploitation attempts.
The included tools are:
The first tool is the "user friendly" version. When it's executed, all running processes will be scanned and protected. This could be executed by a regular user, but ideally, it should be executed as "administrator."
The second tool is for "custom" users, it receives the Process ID parameter set by users. This should enable all users to protect only the processes they want.
Using either tool mentioned above and protecting a running program compiled with code that has the vulnerability, we can see the injected patch in the process memory:
Protecting "Skype v184.108.40.206" of the "VCL Library Heap Overflow":
Now, I invite you to extend this workaround for 64 bits and to support DLL scanning in runtime!
As you can see, it's sometimes possible to apply third party security patches in runtime, without source code and without having to wait for the vendor's official patch.
Obviously, this is not the ideal solution. We always hope that effective patches will be distributed by vendors in a timely manner. But sometimes, the "third party" security solution can be equally or more effective than the alternative.