FS#72996 - texlive-core contains (/uses?) vulnerable log4j library
Attached to Project:
Arch Linux
Opened by Vincent Van Houtte (zenlord) - Monday, 13 December 2021, 14:29 GMT
Last edited by Rémy Oudompheng (remyoudompheng) - Monday, 27 December 2021, 21:35 GMT
Opened by Vincent Van Houtte (zenlord) - Monday, 13 December 2021, 14:29 GMT
Last edited by Rémy Oudompheng (remyoudompheng) - Monday, 27 December 2021, 21:35 GMT
|
Details
Description:
Scanning my system for references to the vulnerable log4j packages, I came across this hit: for f in $(find / -name '*.jar' 2>/dev/null); do echo "Checking $f..."; /bin/unzip -l "$f" | grep -F org/apache/logging/log4j/core/lookup/JndiLookup.class; done Results in: ... Checking /usr/share/texmf-dist/scripts/arara/arara.jar... 2937 2020-11-06 14:03 org/apache/logging/log4j/core/lookup/JndiLookup.class ... "pacman -Qo" shows that /usr/share/texmf-dist is owned by the package texlive-core Additional info: * package version(s) Arch is fully updated. texlive-core is at version 2021.58710-2 * config and/or log files etc. None. * link to upstream bug report, if any https://www.cvedetails.com/product/37215/Apache-Log4j.html?vendor_id=45 Steps to reproduce: None - have texlive-core installed. Marking this a 'high' severity, given the rumours that this exploit is under active attack. Not sure whether this package would make a machine vulnerable or not, so feel free to downgrade the severity. |
This task depends upon
Closed by Rémy Oudompheng (remyoudompheng)
Monday, 27 December 2021, 21:35 GMT
Reason for closing: Fixed
Additional comments about closing: texlive-core 2021.61403-1
Monday, 27 December 2021, 21:35 GMT
Reason for closing: Fixed
Additional comments about closing: texlive-core 2021.61403-1
[1] https://gitlab.com/islandoftex/arara
I have proposed a (probably naive) merge request to get the ball rolling. On my system I decided to uninstall texlive-core to be on the safe side.
The only theoretical attack vector against arara would be running it on an untrusted TeX file. In case arara tries to log part of this untrusted input (e.g. to inform the user about a malformed rule), it could be susceptible to the arbitrary code execution vulnerability CVE-2021-44228. However, running arara on untrusted TeX files by design allows you to run arbitrary commands anyway, even without exploiting the log4j issue: you can e.g. just use a directive like "% arara: pdftex: { shell: yes }" in the TeX file, then execute arbitrary commands using \write18{...}. Hence running arara on untrusted input is never safe anyway, and CVE-2021-44228 does not provide an attacker with a greater scope of action.
Also note that arara is an entirely optional part of the texlive-core. It will never be called automatically by one of the other tools, you have to manually invoke /usr/bin/arara on a TeX document for it to get executed.
Bumping the log4j version that upstream arara uses certainly seems like a good idea regardless, but I do not think any immediate action regarding the texlive-core Arch Linux package is required.
I have absolutely no clue how serious this incident is for arara or for texlive-core, but running a new build takes away all concerns ;).