Update on May 2
Adobe has confirmed this vulnerability and has scheduled a patch release for May 14.
Looking back this year’s RSA Conference, you might have the feeling that the current threat landscape is primarily a series of advanced attacks. This concept includes well-known advanced persistent threats (APTs) and zero-day vulnerability exploits. To respond to this trend in threats, McAfee Labs has launched several innovative projects, one of which we call the advanced exploit detection system (AEDS). The AEDS is based on our in-depth understanding of application security, which comes from our long-term cutting-edge research efforts. We have already seen some interesting results that reflect the effectiveness of the project.
Recently, we detected some unusual PDF samples. After some investigation, we successfully identified that the samples are exploiting an unpatched security issue in every version of Adobe Reader including the latest “sandboxed” Reader XI (11.0.2). Although the issue is not a serious problem (such as allowing code execution), it does let people track the usage of a PDF. Specifically, it allows the sender to see when and where the PDF is opened.
The danger is that if the second parameter is provided with a special value, it changes the API’s behavior. In this situation, if the UNC resource exists, we see the warning dialog. However, if the UNC resource does not exist, the warning dialog will not appear even though the TCP traffic has already gone.
The following screen capture shows the outgoing traffic:
How does this affect users?
Is this a serious problem? No, we don’t want to overvalue the issue. However, we do consider this issue a security vulnerability. Considering this, we have reported the issue to Adobe and we are waiting for their confirmation and a future patch. We are also hiding the key details of the vulnerability to protect Reader users. We may update this post at some point after we see a patch from Adobe.
Who is exploiting this issue?
We have detected some PDF samples in the wild that are exploiting this issue. Our investigation shows that the samples were made and delivered by an “email tracking service” provider. We don’t know whether the issue has been abused for illegal or APT attacks.
Conclusion and protection
This interesting case highlights the point that privacy protection is a part of security. It shows that we can form different opinions depending on our goals (such as security protection vs. email tracking service).
This case also demonstrates that we need to constantly explore methods of detection because these examples won’t trigger memory corruption or code execution. Some of the most advanced detection technologies in the industry failed to detect them. We are happy to see that our AEDS is filling the gap.
Thanks to my colleagues Bing Sun, Xiaobo Chen, and Chong Xu for their help with this investigation.