Patch Verification Process and Silently Fixed Vulnerabilities

By Dmitriy Pletnev

In one of our past blog entries my colleague Stefan Cornelius talked about the importance of verifying vulnerability reports. One of the points mentioned was the verification of patches. Today, I am going to discuss the patch verification process performed by Secunia in greater detail.

When vendors release patches the Secunia Advisories team reviews the published information (e.g. changelogs, release notes) in order to update current advisories or release a new one based on information provided. For outstanding vulnerabilities the patches may also be analysed to make sure that fixes properly address the vulnerability and not just one or more attack vectors.

One of the benefits of performing additional patch analysis is that it allows us to gain a better understanding of the application and accurately evaluate the vulnerability core problems, fixes, and impacts (as e.g. discussed in our blog entry about the impact of a vulnerability fixed by MS10-063. Occasionally, we also uncover new vulnerabilities or identify silently fixed vulnerabilities (i.e. vulnerability fixes not mentioned by a vendor).

As an example of the latter, I am going to discuss a recently patched ActiveX control from SonicWALL ( Specifically, the End-Point Interrogator/Installer ActiveX control provides software installation and interrogation functionality and is used by the SonicWALL SSL-VPN E-Class remote access devices. The control allows administrators of the remote access solution to manage end user devices via a policy driven configuration stored on the SSL-VPN device.

Originally, a format string error was reported and, as usual, a member of the Secunia Advisories team was tasked with confirming the validity of the vulnerability report. As the vendor also released a patch to address a format string vulnerability in the ActiveX control, this also had to be analysed more in-depth to ensure that it fixed the reported vulnerability and that the fix was proper.

Via static analysis it was confirmed that the "AuthCredential" property handling code passed the user-supplied string as argument to an internal logging function that subsequently used it as the "format" parameter to vsnwprintf(), which via specially crafted format specifiers in the string allowed overwriting memory with attacker-controlled data. We also confirmed that the fix properly addressed the vulnerability via changes to the logging function.

During the binary patch diffing process (between versions and we noticed that several methods were updated. Specifically, the handling of certain string arguments was changed to no longer concatenate strings into stack buffers via wcsncat(), using the length of the source strings as the “count” parameter in an unsafe manner.

These seemed like buffer overflow fixes and prompted an in-depth review of the changes that lead to us concluding that a large number of stack-based buffer overflows had been silently fixed related to the parsing of certain methods provided by the ActiveX control. After proving that the vulnerabilities were exploitable, the results of our findings were added to our advisory both in the public description and in more detail in the “Extended Description” section available to customers on our VIF, EVM, and BA solutions.

This is just one example of many daily cases where the verification process performed by Secunia uncovers additional details that ensures we can provide the most trustworthy and reliable Vulnerability Intelligence both to customers and the community.

Stay Secure,

Dmitriy Pletnev
Security Specialist