This is fixed in Version 2.4.1 (modernized File-system Interface uses O_EXCL to create files in the tmp folder).
I would suggest adding a security note to the 2.4.1 release notes.
Details
Jansi extracts a .so library to the global temp folder to implement it's terminal features via OS-depended native code.
It actually creates to files:
jansi-{random}.so.lck Lock file
jansi-{random}.so library file.
Although random is a secure random string which cannot be
predicted this approach creates a race condition between step 1 and
step 2.
The exploit watches for jansi-*lck file creation in the tmp
folder.
Once this file is created, it prepares a world-writable
jansi-{random}.so to get ahead of the Jansi Java program which
itself doesn't check if this file already exists and just overwrites
it (keeping it's world-writeable permissions).
Now the exploit watches for a CLOSE_NOWRITE event of the jansi-{random}.so
file and replaces this file via a atomic rename of its own jansi.so file.
This is fixed in Version
2.4.1(modernized File-system Interface usesO_EXCLto create files in thetmpfolder).I would suggest adding a security note to the
2.4.1release notes.Details
Jansiextracts a.solibrary to the global temp folder to implement it's terminal features via OS-depended native code.It actually creates to files:
jansi-{random}.so.lckLock filejansi-{random}.solibrary file.Although
randomis a secure random string which cannot be predicted this approach creates a race condition between step 1 and step 2.The exploit watches for
jansi-*lckfile creation in thetmpfolder. Once this file is created, it prepares a world-writablejansi-{random}.soto get ahead of theJansiJava program which itself doesn't check if this file already exists and just overwrites it (keeping it's world-writeable permissions).Now the exploit watches for a
CLOSE_NOWRITEevent of thejansi-{random}.sofile and replaces this file via a atomic rename of its ownjansi.sofile.Full details and PoC