Sergey Nivens - Fotolia
How can a NULL pointer dereference flaw create a DoS attack?
A flaw in the open source graphics library libpng enabling denial-of-service attacks was discovered. Expert Michael Cobb explains how the vulnerability works.
A low-severity vulnerability was found in all versions of the open source graphics library libpng dating back to 1995. The vulnerability, which has been patched, could have been used for remote denial-of-service attacks. What was the flaw, and how did it go undiscovered for so long?
Portable Network Graphics (PNG) is the most widely used, lossless image compression format on the internet, created as a non-patented replacement for the patented GIF.
Libpng is the official PNG reference library and contains C functions for handling PNG images. It is an open source, platform-independent library that was written as a companion to the PNG specification to make it easier for developers to support the PNG file format in different applications. It is frequently used in both free and proprietary software, such as Ubuntu, Debian, Red Hat, Chrome and Firefox, either directly or through the use of a higher level image library.
The libpng project announced patches at the end of 2016 to fix a NULL pointer dereference bug, tracked as CVE-2016-10087, which has existed since version 0.71 of the library, released in June 1995. A NULL pointer dereference occurs when a program attempts to read or write to memory with a NULL pointer, which results in a segmentation fault as the code triggers a memory access violation. The vulnerability has been fixed in versions 1.6.27, 1.5.28, 1.4.20, 1.2.57 and 1.0.67.
The flawed code exists in the png_set_text_2 function and was discovered and patched by Patrick Keshishian. The null pointer dereference vulnerability could have enabled a remote, unauthenticated attacker to launch a denial-of-service (DoS) attack by causing the affected system to crash and go offline.
Although a DoS attack is serious, this vulnerability is limited to PNG editing applications -- those only capable of viewing PNG images are unaffected -- and requires an unlikely sequence of instructions, as well as active user input, to produce a system crash. An application has to load a text chunk into the PNG structure, delete it all and then add another text chunk to the same PNG structure.
The libpng project noted there are no known PNG editors susceptible to the vulnerability without interactive user input, which is why its severity is only rated as low. An attacker couldn't craft a special PNG image to trigger this vulnerability either; it can only be triggered interactively or through tools that can queue the necessary sequence of commands. There are plenty of more efficient ways to initiate a DoS attack without having to target a specific application.
Just because a program's source code is available doesn't mean that every function has been reviewed and tested by security experts. It took two years before anyone spotted the Heartbleed coding error, even though now it seems glaringly obvious. Reading through the change log of libpng reveals that the png_set_text_2 function has been changed various times to plug different memory leaks, so it is surprising that yet another coding flaw has come to light after so much time.
In July 2009, the change log in version 1.4.0beta70 stated, "Avoid a possible NULL dereference in debug build, in png_set_text_2. (bug introduced in libpng-0.95, discovered by Evan Rouault)." Version 1.6.0beta20, released in March 2012, revised png_set_text_2 to avoid potential memory corruption and fixed CVE-2011-3048. In January 2013, version 1.6.0beta39 added overflow detection in png_set_text_2 (CVE-2013-7354).
The png_set_text_2 function is almost 200 lines of code found in pngset.c and, hopefully, this time it has been robustly checked. Fortunately, this NULL pointer dereference vulnerability was classified as low severity, but more serious vulnerabilities found in open source frameworks and component libraries are often rapidly exploited by hackers, as these attacks can be automated with the knowledge that any application built using the flawed code is vulnerable until a patch is released and installed.
Emergency response teams need to have a rapid reaction plan in place for installing any critical patches released for shared components in use on the network.