Arbitrary File Read in Jenkins via args4j (CVE-2024-23897) - is this another log4j?

Please note that this analysis covers the vulnerability of @ expansion, not the entire attack chain possible from the advisory.

Background

The hot thing in the cyber security press this morning (25 JAN 2024) is a vulnerability in Jenkins allowing attackers to read arbitrary files. Jenkins has had a few vulnerabilities over the years, likely due to its incredible popularity and dominant marketshare in the CI/CD space inviting much code analysis and scrutiny.

The large market share along with the sensitive nature the data make it a hugely popular target among attackers. If successful, attackers can pivot into an organization’s cloud infrastructure using the highly privileged and long lasting accounts contained within.

When a vulnerability is released for Jenkins, we potentially have a very big issue on our hands, but is that the case for CVE-2024-23897? Let’s dig in.

The Announcement

Per Jenkins:

“This command parser has a feature that replaces an @ character followed by a file path in an argument with the file’s contents (expandAtFiles). This feature is enabled by default and Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable it.” Jenkins 2.442, LTS 2.426.3 disables the command parser feature that replaces an @ character followed by a file path in an argument with the file’s contents for CLI commands.

The Code

Examining the patch we can see that they have added ALLOW_AT_SYNTAX to allow/disallow what was called out in the announcement as the vulnerable code path, the @ file expansion. Also, we can follow the bread crumbs in that code to identify the vulnerable code in args4j here:

Here we have the logic from args4j where we test the first character for @-ness, and read all the lines of the file if true:

The Vulnerability

@ expansion seems like a convenient feature to launch java applications from the command line using a file full of arguments instead of each argument separately, and I’m not sure I’m comfortable calling it a vulnerability per se. This vulnerability is due to arbitrary user input arriving at a command line argument. It is important to highlight the difference between this and a wildcard expansion vulnerability, which IMO is much worse due to their arbitrary and unpredictable nature.

Impact

Do other software projects use this library in a vulnerable way? A github search reveals that is a pretty popular library, but a quick survey of search results shows most of the importers of this are command line utilities intended to interact with larger projects like these minecraft utilities, or are unlikely to allow rich user interaction via web interface (such as stratum-proxy)

Conclusion

For these reasons I don’t think we have another log4j type mega-bug in args4j, but rather a fairly straightforward input validation / surprise feature problem that is likely only to be exploited by authenticated users in Jenkins, and will have limited impact in other software utilizing the args4j.