The vulnerability is a classic path traversal issue in IzPack, a Java-based installer framework. The root cause is the lack of validation of the targetPath attribute within a PackFile object, which is read from the installer package.
My analysis of the provided patches (commits 4233ba38d0f1825f9cf3e0204e5261a5498e29d8 and 8b7c6792c4fe85e3b1759c106aae39b904848466) reveals two key locations where the vulnerability is addressed:
-
com.izforge.izpack.api.data.PackFile.<init>: The constructor of the PackFile class is the first point where the malicious targetPath is introduced into the system. The patch adds a validateTargetPath method that is called from the constructor to sanitize the input. The vulnerable function is the constructor itself, which, in its pre-patch form, failed to perform this validation.
-
com.izforge.izpack.installer.unpacker.UnpackerBase.unpack: This method consumes the PackFile object and performs the file extraction. It uses packFile.getTargetPath() to determine where to write the file. The patch adds validation logic within this method to ensure the final path is canonical and resides within the intended installation directory. The vulnerable function is unpack because it blindly trusted the path provided by the PackFile object.
During exploitation, a profiler would show a call stack involving the UnpackerBase.unpack method, which in turn would be processing a PackFile object created by its vulnerable constructor. Therefore, both functions are critical runtime indicators of this vulnerability.