Reflections on the PDF vulnerability

Introduction

Earlier this month we wrote about a vulnerability in the PDF specification that could be utilized to run malicious programs embedded in a PDF file. Proof-of-concept code was published, and it was expected that real-life malware that used this technique might appear soon. See our article Scary technique utilizing functionality in the PDF specification for more information.

Updates about this particular vulnerability

The original publication by Didier Stevens caused a lot of discussion in the media and among security experts. Jeremy Conway introduced a technique that enabled malicious code to infect other, existing PDF files by clever use of incremental updating technique. See for example his clearification in this blog item 6 April. A combination of these two methods makes the potential for malware propagation even more scary.

14 April M86 Security Labs published information about an email, which looked like it was sent from Royal Mail. This email has a PDF attachment that uses the /LAUNCH technique to install malware in the Zeus/Zbot family. The use of Didier Stevens' proof-of-concept technique however, is only rudimentary. The malware does not utilize the social engineering technique described by Stevens to customize the dialog box to trick users into accepting to run the program. Didier Stevens characterizes this attack as "with little to no real sophistication" in his posting 15 April.

We expect more malware, which utilizes the PDF vulnerability, to appear soon. It also seems safe to assume that more advanced malware variants will come along, combining the various weaknesses in the PDF specification that have been generally known lately.

Generalization

This in itself is of course interesting and frightening. The main purpose of this article however, is to make some general points.

Increasingly important: The time from a vulnerability is known to malware is seen in the wild

The /LAUNCH example above shows that it does not take many days from information about a vulnerability is published, till it is being used by malicious software. In this case approximately two weeks.

This of course has as a consequence that software vendors are under heavy pressure to make amendments in their applications, and to publish security patches in order to secure their applications from exploitation. Big software vendors, like Microsoft and Abobe, publish security updates at fixed intervals (monthly and quarterly respectively), a policy which has its merits regarding customers' needs to be able to plan the updating process. Seen from a pure security point of view however, these updating strategies may seem too infrequent. The vendors are therefore often "forced" to publish important updates outside the fixed dates, like the out-of-band update of Microsoft Internet Explorer late March this year.

In recent years we have seen an improvement in the software vendors' ability to create and publish patches quickly after a vulnerability has been publicly known. Nevertheless it is still a fact that there is a window of opportunity for creators of malicious programs to spread malware, which exploits unpatched vulnerabilities.

Other layers of defense are then needed in the interim period. Updated antivirus products should be mentioned as one example. In normal circumstances the antivirus vendors will be able to create malware signatures for a particular type of malware much faster than the software vendor is able to patch the underlying vulnerability. Antimalware products that are able to detect malware even before virus signatures are available, may be even more effective. Antivirus products using techniques like Norman SandBox®, are examples of this. Nor should each an every individual's own ability to protect himself by using general common sense be underestimated.

[Note that in the particular case with the /LAUNCH vulnerability, vendors' patching ability do not apply as usual. This vulnerability is in the specification of the format itself and not in the applications used to display/edit files in that format. Changing a specification, which is approved by the International Organization for Standardization, will usually take some time.]

Functionality: Security's worst enemy?

The /LAUNCH vulnerability also shows a paradox, which unfortunately is common for several vulnerabilities in software.

The PDF specification has functionality that seems quite far-fetched in a format which goal is

(...) to enable users to exchange and view electronic documents easily and reliably, independent of the environment in which they were created or the environment in which they are viewed or printed. ¹

Numerous security experts have criticized this, see for example F-Secure's quite harsh blog comment "Does PDF stand for Problematic Document Format?".

The same applies for software programs. Several applications are bloated with (more or less obscure) functionality, which makes the software prone for vulnerabilities and subsequent exploitation. A rule-of-the-thumb is that one added new function is one potential new vulnerability,

Thus we have the situation that software vendors add new functionality to their software in order to satisfy some customers' requests. On the other hand this added functionality will (often) result in more insecure products for all the product's customers. 

Unfortunately - at least until recently - neither the average user, and in particular nor media commenters reviewing software, have been focusing on this. Broadly spoken, the tendency has been to say that a product with 113 functions is better than the competing one which has only 112. The obvious reason why is of course that it is difficult to review and compare products based on unknown and potential vulnerabilities.
As the focus on security in general, and application vulnerabilities in particular, seems to be increasing, this may slowly change.

[Another spin-off from bloated functionality in software is that the products often are cumbersome to use for the average user. This however, is a discussion far beyond the scope of this security article.]

References

¹ Document management — Portable document format — Part 1: PDF 1.7 - Introduction