In this paper, the recently fixed security vulnerability cve-2019-8014 in Adobe Acrobat Reader / Pro DC is analyzed in detail. Interestingly, Adobe fixed a similar vulnerability cve-2013-2729 six years ago. It is because of the incomplete repair of this vulnerability that cve-2019-8014 has been left for as long as six years. This article also discusses how to write exploit code for such vulnerabilities.

Author: Ke Liu of Tencent security Xuanwu Lab

0x01. Vulnerability introduction

Adobe released security notice apsb19-41 for Adobe Acrobat and reader in August. As usual, this update fixes a lot of vulnerabilities. When I check the corresponding vulnerability announcement on zdi, my eyes are quickly attracted by zdi-19-725 / cve-2019-8014, because the vulnerability related to bitmap parsing in module acroform is very rare. Some announcement information of the vulnerability on zdi is as follows:

This post provides detailed analysis for CVE-2019-8014 which was fixed in Adobe Acrobat Reader / Pro DC recently. Interestingly, it’s a patch bypass of CVE-2013-2729 which was fixed six years ago. This post also discusses how to exploit the vulnerability.

Author: Ke Liu of Tencent Security Xuanwu Lab

0x01. Introduction

Adobe released security updates for Adobe Acrobat and Reader in APSB19-41 in August. As usual, lots of vulnerabilities were fixed in the updates. When I was reviewing the corresponding advisories on ZDI , my attention was attracted by one of them: ZDI-19-725 / CVE-2019-8014 . Following text is the title and description of this case:

Garbage classification is a hot topic recently, which often appears in various news reports. It happens that the author is also studying garbage collection recently, but this garbage is not that garbage. The author is studying garbage collection in programming language (hereinafter referred to as GC).

For the introduction of GC, the Japanese book "garbage collection algorithm and implementation" published in 2010 is highly recommended. When I read part of the book, I just thought of several related loopholes, so I wrote an article to record it.

0x01. Why

Thousands of roads, compile the first!

When compiling open source software on windows, there are always various kinds of pits to fill.

0x01. Vulnerability introduction

I'm going to use my spare time to learn some knowledge about the exploitation of browser vulnerabilities. Just recently, a field exploitation vulnerability cve-2019-5786 has emerged from chrome. There are also two detailed analysis reports (from Exodus intelligence and McAfee Labs) on the Internet, which can be used to learn the principles and utilization skills of vulnerabilities.

The security notice of chrome 72.0.3626.121 shows that the vulnerability cve-2019-5786 was found to be exploited in the field by clement lecigne of Google thread analysis group (with cve-2019-0808, a null pointer vulnerability in the windows kernel, it can realize the right operation under Windows 7).

0x01. Problem description

When testing a program at the weekend, it was found that its inexplicable crash was in a function of a system's own DLL, and it was difficult to see the cause of crash directly. After analysis, it was found that it was caused by improper use of C language setjmp and longjmp. So what does this have to do with the title of the article? In the process of analysis, the author uses the processor breakpoint / data breakpoint of WinDbg to track the read and write operations of a stack variable. Theoretically, this breakpoint will hit many times, but only once in fact. This phenomenon is caused by the unexpected change of the values of ESP and EBP registers caused by improper use of setjmp and longjmp.

Posted on 2019-01-01 | In Default May you always have beginner’s mind.