Use-after-Free 0-day Bugs in Chrome

Phumin Walaipatchara

Dec 12, 2019·13 min read

Disclaimer: This article neither was written by researchers nor should be served as a reference. This article is a security news assignment of Network Security course at Boston University. We, the authors, do not guarantee correctness and accuracy and do not take any responsibility for the damage that this article might cause. Refer to the original references for accurate details about the vulnerability.

The Google Chrome Zero-Day vulnerabilities are “use-after-free vulnerabilities” which are memory flaws where attempts can be made to access memory after it has been freed. This vulnerability can be used by hackers to hijack a user session and execute malicious code. Recently two flaws have been discovered: one that affects Chrome’s audio component (CVE-2019–13720) and one that affects Chrome’s PDFium library (CVE-2019–13721).

Use-after-Free (UaF): What is that?

When a memory block is dynamically allocated (e.g. using malloc()), the memory allocation routine will try to find an empty memory block in the heap (or extend the heap if there isn’t any), generate a memory chunk metadata block that is part of a memory chunk linked list to reflect that the memory location is now allocated/in use, then return the pointer to the newly created memory chunk. When that pointer is deallocated, the memory chunk is updated/merged accordingly to reflect that the block is now free to be allocated again. However, this does not guarantee the clearing of data, nor, since the now-deallocated pointer is not actually nullify, that the previously allocated memory cannot be referenced again using the same pointer.

UaF exploitation in CVE-2019–13720

Essentially, the attacker will try to exploit a race condition due to “missing proper synchronization” between threads using the browser’s built-in BigInt() function and various alloc-then-free routine and trigger UaF condition to leak some real address information to defeat ASLR (Address Space Layout Randomization). Once that’s done and real address information is gathered, it will try to spawn multiple large objects (hence the use of BigInt) to build a deterministic heap structure. With this, the attacker can now at the same time spray the heap, possibly causing arbitrary code execution.

In this case, the malicious Javascript on the infected site will make multiple AJAX requests to download the RC4-encrypted file, which when decrypted, concatenated and deobfuscated will become a new JS code that will mount the UaF attack to set up the shellcode to decrypt the final payload — a binary file name worst.jpg — into an executable updata.exe which is a compressed RAR SFX containing two files, iohelper.exe and msdisp64.exe. According to Karpersky’s blog:

“The main module (msdisp64.exe) tries to download the next stage from a hardcoded C2 server set. The next stages are located on the C2 server in folders with the victim computer names, so the threat actors have information about which machines were infected and place the next stage modules in specific folders on the C2 server.”

How was it discovered?

On October 29, 2019, Anton Ivanov and Alexey Kulaev, the Head of Advanced Threats Research and Detection at Kaspersky discovered the (CVE-2019–13720) flaw that exists in Google Chrome’s audio component (1) by using Kaspersky endpoint products and the Exploit Prevention Component and immediately reported the vulnerability to Google (7).

Kaspersky’s Exploit Prevention Component works by tracking executable files that are run by vulnerable programs. Whenever an executable file from an application that is not authorized by the user tries to run, the component blocks it from running and stores details about this attempt in the Exploit Prevention report (12). In particular the Automatic Exploit Prevention technologies store this activity and detect the source that attempts to launch the harmful code. The source may come from the software itself or be the result of an exploit. “Certain types of exploit, particularly those used in drive-by downloads (i.e. exploits launched through a malicious web page), need to fetch their payload from another website before executing it. AEP can trace the origin of such files, identify the exact browser that initiated the download and retrieve the remote web address for the files”(13). This case relates to the CVE-2019–13720 vulnerability because the attacker initiates his attack via a malicious webpage. Specifically, it pertains to the stage of the CVE-2019–13720 vulnerability where malicious JavaScript is used to make multiple AJAX requests to get the RC4 file that would then be decrypted to get the UaF exploit. The Kaspersky researchers observed the Exploit Prevention report and noticed indicators of harmful activity that occurred after a user finishes using audio components from Chrome.

The researchers found that “the flaw was first injected into a Korean news website. When people visited the site, a script from a third-party site would load and see whether the machine was one worth attacking. According to Kaspersky, the attackers designed the code to only attack Windows machines running Chrome versions 65 or newer” (15).

The similar but less threatening bug, CVE-2019–13721, which affects PDFium, was discovered on October 12, 2019 by a researcher under the name “banananapenguin” who received a $7500 bounty award through Google’s vulnerability disclosure program for the finding. The technical details of this discovery have not been revealed and so far, there has been no exploitation of this vulnerability.

Addressing UaF 0-day in Chrome

In the normal case that the vulnerability was discovered by the researchers, the software developer will be granted some period of time in order to develop a patch/fix and for the users to apply that patch/fix. However, since this vulnerability (CVE-2019–13720) is a zero-day vulnerability, that is being exploited in the wild, Google, as the Chrome developer, did not be aware of the flaw and have enough time to develop a patch to fix the issue. In addition, there was an attack being carried out, so the most important and proper action to handle this vulnerability is to limit the damage. As can be seen from figure that the domain being used for the attack is *.behindcorona[.]com, major DNS provider including, but not limited to, Google public DNS (8.8.8.8), Cloudflare (1.1.1.1), and Quad 9 (9.9.9.9) as well as institutional DNS server such as BU DNS answers DNS query for *.behindcorona[.]com as localhost(127.0.0.1) or non-existent domain (NXDOMAIN). Although this is a temporary fix carried out by major DNS provider in addition to Google, it is effective to prevent normal users from establishing a connection to the attacker’s command and control server (C&C) while allowing more time to develop a patch/fix and for users to update Chrome browser.

Not so long after the attack details was published, Google released a new version of Chrome browser (78.0.3904.87) on October 31, 2019 that has two security fixes as followed:

CVE-2019–13720: Use-after-free in audio
CVE-2019–13721: Use-after-free in PDFium

Google urged users to update Chrome browser as soon as possible despite automatic update mechanism implemented in Chrome browser. In spite of release new version to fix the vulnerabilities, the fix released is a temporary migration as the actual root of the vulnerabilities lies within the memory management system that does not nullify the pointer’s address after freed.

On the other hand, not only Google has been working on the fix, but Kaspersky also has programs to work around the vulnerabilities, namely, Kaspersky Endpoint Security for Business, Kaspersky Anti Targeted Attack Platform, and Kaspersky Intelligence Reporting customers. All Kaspersky software use behavior-based detection, which means the vulnerabilities can still be exploited, but the damage is prevented or quarantined.

Addressing UaF: the Hard Way

The attack could have been prevented if developers at Google had been more careful with simple mistakes and quality assurance was more thorough. Based on the details of the discovered vulnerability, some bad practices that the developers could have made are:

Naming the variable the same as a memory structure (lead to accidentally mem alloc the size of the variable pointer, not the struct)
Dealloc pointer variables using unsafe/unsanitized methods/functions
Dealloc public pointer variable in function (especially damaging in async language/parallel execution)
Duplicating pointers without tracking and nullifying them after use.

Some preventives measures they could have used are:

Easy:

Nullify pointer variable (e.g. assign NULL to the deallocated pointer variable) upon mem dealloc
Nullify pointer destination (e.g. point them to an invalid memory region) upon mem dealloc
[C++11] Use smart pointer
[C++11] Use unique pointer
[C++11] Use shared pointer

Hard(er):

Track and handle copied pointers (esp. across threads of execution)
Handle dangling pointers

If the massive volume of code in Google’s software code made it difficult for developers to manually nullify all dangling pointers and check which pointers are associated with which objects, the developers and testers could alternatively have used a system such as DangNull, which, as described in a research paper by Lee Byoungyoung et. al. at the Georgia Institute of Technology, detects temporal memory safety violations during runtime. Since UaF flaws like the one in chrome’s audio component and in PDFium stem from the fact that pointers are not nullified after the target object is freed, DangNull automatically performs the nullification of pointers that do not point to anything. DangNull works because it addresses the root cause of UaF flaws, “does not rely on the side effects of violations that may be masked by attacks, and checks object relationship information using object range analysis on pointers” (19).

Despite these potential preventive measures, it is difficult to predict or spot such a vulnerability in such a large product.

Is Google legally and/or ethically guilty?

Google did not violate any legal laws and acted according to their “Legal frameworks for data transfers” while implementing the fix, which said to respect the user’s privacy. However, if users imitate the ways Google did to update his or her personal developed software, I wonder if legal agents will rush there since the transparently update that Google did is rather forceful and not according to users’ will or decision. Moreover, there is no way to stop or block the update from google since they have already removed the option to do so as stated in “How to DISABLE Google Chrome Auto-update?”. These can be debatable on “Is the a hole in the law?”

Nevertheless, forcing the software to update is still better in term of safety, since ignoring is way worse. Companies/Service providers also have a choice of ignoring the vulnerabilities by excusing that “it is false alarm” or “never knew before” while legal law, even CFAA or Data Protection Act, since it is not count as assisting/commited the crimes. These can clearly be seen as a vulnerability in the law itself. If there is also a bug-bounty system where the white hat hacker get rejected on their bug report which can be clearly proven. They can report to government with the evidence that their report is exceeding the given period of time or get rejected without reasonable explanation. However, if what they prove is appear to be false report, then they also have to be punished as they deserve, too.

There is currently a lack of evidence to link this attack to known threat actors; the only evidence thus far was that the malicious JavaScript of the attack was injected in a Korean-language news portal (16). If the threat actors had performed their crime in Korea with the intent of stealing money, they would, under the Unfair Competition Prevention and Trade Secret Protection Act, be punished with up to five years of prison or charged up to KRW 50 million. If the threat actors’ motivation was to collect information about another person’s identity, they would be punished with imprisonment of up to three years or fined up to KRW 30 million (17).

On the other hand, if this crime is committed in United State, assuming in California, there is also a specific laws with corresponding penalties. According to “502 subdivision(c) and so on in CHAPTER 5. Larceny [484–502.9] in PENAL CODE — PEN, PART 1. OF CRIMES AND PUNISHMENTS [25–680] ( Part 1 enacted 1872. ) TITLE 13. OF CRIMES AGAINST PROPERTY [450–593g] ( Title 13 enacted 1872. )” from California Legislative Information, we can clearly see that the hacker commit several illegal acts as following:

Knowingly accesses and without permission:

alters, damages, deletes, destroys, or otherwise uses any data, computer, computer system, or computer network in order to either (A) devise or execute any scheme or artifice to defraud, deceive, or extort, or (B) wrongfully control or obtain money, property, or data.
takes, copies, or makes use of any data from a computer, computer system, or computer network, or takes or copies any supporting documentation, whether existing or residing internal or external to a computer, computer system, or computer network.
adds, alters, damages, deletes, or destroys any data, computer software, or computer programs which reside or exist internal or external to a computer, computer system, or computer network.
accesses or causes to be accessed any computer, computer system, or computer network.
adds, alters, damages, deletes, or destroys any data, computer software, or computer programs which reside or exist internal or external to a public safety infrastructure computer system computer, computer system, or computer network.

The corresponding penalties will be “a fine not exceeding five thousand dollars ($5,000) to ten thousand dollars ($10,000) due to the seriousness of caused damages/injuries, or by imprisonment in a county jail not exceeding one to three year(s) according to the seriousness of caused damages/injuries, or by both that fine and imprisonment” for each illegal act.

Although Google did not violate any legal laws while implementing fix, the ethics of the fix that they created can be debated.

Since the auto-update fix that Google provided for its users’ browsers is automatic and takes action transparently without giving users the choice of making their own security decisions, there is a dilemma between distributing the patch as rapid as possible and asking for user’s consent before applying an update for patching. Therefore prior to this auto-update program, Google was encouraging users to update their own browser.

Another ethical issue that is raised is that Google promised to provide confidentiality to the bug details in their alert: “‘Access to bug details and links may be kept restricted until a majority of users are updated with a fix’” (1). Google would know that the majority of users are updated with a fix by recording statistics about Chrome version the user is using by gathering the user agent and can reveal vulnerability details once the “majority” of users updated their Chrome browser. True to their promise, Google did not reveal bug details in their security patch details. However, other websites have information about the attack. In particular, Kaspersky published technical details on their blog about the attack (2). It is questionable whether Kaspersky has violated Google’s promise, depending on the level of detail to which Google was referring.

Lastly, although the software developer has no legal responsibility for being negligible, the software developer has placed their liability and fame into risk if the vulnerability is not fixed in a timely manner. Nevertheless from a humanist perspective, it is a challenge to write code that is completely bug-free. The quality assurance team and all who contribute to making this software should do a more thorough job in order to make sure the software is secure, since it will be used by many.

Final Words on UaF 0-day in Chrome

The Google Chrome Zero vulnerabilities, Operation WizardOpium, are use-after-free vulnerabilities that are able to hijack a user session and wrongly modify/steal personal details of users. To carry out the attack, the victims are supposed to be ones who visit a malicious website by themselves. Two related flaws, CVE-2019–13720 and CVE-2019–13721, were discovered by Anton Ivanov and Alexey Kulaev, and bananapenguin respectively. The auto-update has already been deployed to temporarily prevent the problem while buying time for developers to find a permanent solution. However, the method of auto-update is debatable on how they deliver the update transparently. Despite relying on passive user interaction in order to exploit the vulnerability the attacker is guilty as a result of unauthorized access and causing damage. The punishment will suitably adjusted to their crime in terms of, for instance, the number of victims and/or monetary loss. In fact, the potential attacker could report the discovered vulnerability to the software developer to encourage the security of the software. Nonetheless, the potential attacker can monetize the vulnerabilities and earn more than reporting to the software developer. The mentioned dilemma is yet to be settled since the software developer cannot afford awarding as much as what the potential attacker can monetize the vulnerabilities and the potential attacker prioritizes money over security responsibility.

Authors: Minh Truong, Chanavee Prasopsanti, Phumin Walaipatchara, Sandra Zhen

References

(1) https://threatpost.com/google-discloses-chrome-flaw-exploited-in-the-wild/149784/

(2) https://securelist.com/chrome-0-day-exploit-cve-2019-13720-used-in-operation-wizardopium/94866/

(3) https://www.tenable.com/blog/cve-2019-13720-use-after-free-zero-day-in-google-chrome-exploited-in-the-wild

(4) https://gadget.co.za/zero-day-bug-hits-chrome/

(5) https://www.malware-killers.com/remove-pdmexploit-win32-generic

(6) https://securityaffairs.co/wordpress/93278/hacking/cve-2019-13720-lazarus-attacks.html This source lists an instance where the vulnerability was exploited)

(7) https://securityaffairs.co/wordpress/93278/hacking/cve-2019-13720-lazarus-attacks.html
(8) https://www.kaspersky.com/blog/google-chrome-zeroday-wizardopium/29126/

(9) https://www.forbes.com/sites/daveywinder/2019/11/01/new-google-chrome-security-alert-update-your-browsers-as-high-severity-zero-day-exploit-confirmed/#42e9d43c70b3

(10) https://www.alston.com/en/insights/publications/2016/09/icyber-alerti-security-vulnerabilities-you-dont-ne

(11) https://www.computerworld.com/article/2488641/major-companies--like-target--often-fail-to-act-on-malware-alerts.html