The Notepad++ Hack: Shared Library Vulnerabilities and One Way to Avoid Them

On March 8th the Notepad++ development community released a news item about a vulnerability in the popular text editor that had been exploited by the CIA. Apparently, in a number of cases, one of the app’s dynamic link libraries (scilexer.dll) was replaced by a modified version of the library built by the CIA. Without the knowledge of Notepad++ users, the altered scilexer.dll file was able to collect users’ data in the background. The Notepad++ community was concerned that this made them vulnerable to attacks from bad actors.

Is this something we need to be concerned about? The answer is a resounding YES. While you probably don’t have to worry about using Notepad++ anymore, as they claim that they’ve fixed this vulnerability, this event does raise some very important questions. Can something similar happen to your apps? Are your shared libraries safe? While it is unlikely that the CIA will spend their resources on hacking your app, someone else might.

The attack described above is nothing new. In fact, the earliest such attacks appeared in 2000. They come in different flavors, such as DLL side-loading and DLL hijacking, and have been employed by a number of malware, including PlugX, HTTPBrowser, Sakula, and more. The idea is very simple — if the executable that depends on a shared library does not perform proper validation, an attacker can replace the library with a malicious one, and the user will not even notice it.

How can you protect your shared libraries against hijacking and modification? Typically, protecting shared libraries entails using sophisticated signature verification and code integrity schemes, security engineering skills that many organizations may find difficult to access. If that is the case with your organization, one of whiteCryption’s products — whiteCryption Code Protection — has a simple fix that eliminates this very problem.

The feature is called cross-checking of shared libraries. Here’s how it can help:

  1. You select specific shared library files delivered with your app (*.dll or *.so files).
  2. Code Protection calculates cryptographic signatures of their binary code, and embeds these signatures into your main app.
  3. At arbitrary places in code, your app invokes a special function to check if the signature of a particular shared library loaded in the memory matches the previously recorded signature. In other words, this function will check if the loaded shared library has not been modified or replaced.