As is described in the documentation linked above: Perl supports a rudimentary taint tracking with -T, which sounds promising both as a security control, and as a way to analyze this bug. Tricking it with ( recursion to combine two benign strings into an evil stringĮven using ( to recurse, the eval only happens at the base case of strings within ” characters, not on combined results from recursively called functions. I was hoping something like backticks would work, but no luck. # (can use seemed like our best bet at getting code execution. # syntax: s/match pattern/replace pattern/modifiers $tok =~ # apply search/replace regex to $tok, saving modified version in $tok Here’s a syntax-incompatible breakdown of what’s happening: Perl syntax and regexes can get a bit ugly. Examining the Idiosyncrasies of Regex and Eval From the vulnerability classification of incomplete sanitization, and the eval being removed, we can tell that we’ll want to focus on getting code execution here.Īt its core, eval is very risky to use on uncontrolled input like this, so any code using an eval like this should be thoroughly audited, or better yet refactored to not require an eval at all. However, the new version uses a search and replace to handle only the intended C escapes, and removes the eval entirely. Looking at the diff, we see that the old version did a search and replace on $tok to sanitize it, then ran an eval on $tok to implement handling of certain escapes like \n. There is recursion on the ( character as well as other handling, but this doesn’t seem to be part of the vulnerability. So, if an annotation was asdf(hjkl”1234”, this function would handle the string as 1234. This code is part of a case that handles text wrapped in double-quote ” characters in ParseAnt. After reading the diff, or just reading other online commentary, we find the following change in the ParseAnt function in the DjVu Perl module, which is used to parse DjVu annotation fields: The vulnerability report for CVE-2021-22204 includes a link to a diff in GitHub for the fixed version for ExifTool. Let’s see if we can figure out what’s going on here. One could imagine the danger this could pose for a web application that accepts user-uploaded images or documents. Interesting! We have arbitrary code execution in a library that may possibly be widely used, that is reachable from a variety of different kinds of input. The bug can be triggered from a wide variety of valid file formats. Improper neutralization of user data in the DjVu file format in ExifTool versions 7.44 and up allows arbitrary code execution when parsing the malicious image.Īdditionally, a referenced email on the OSS-security mailing list says: Here’s a snippet from the CVE-2021-22204 tracking page in NIST’s National Vulnerability Database (NVD): It’s used by GitLab, which is how this issue was originally discovered, and likely many other web applications. For example, it can be used to remove identifying metadata from JPG images. BackgroundĮxifTool is a Perl library and Command Line Interface (CLI) application for reading, writing, and editing metadata in a variety of image and document formats. Most of this was done before other PoCs and writeups were published, but when I became aware of them, I happily took inspiration from these other reports in my own process. Included in this journey are the dead-ends I reached, and my thought process as I went along. This is a narrative walkthrough of how I (like many others) independently built a Proof of Concept (PoC) for CVE-2021-22204.
0 Comments
Leave a Reply. |