CVE-2023-37460

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.

Summary

Using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution.

Description

When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target.

Impact

Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution.

Technical Details

In AbstractUnArchiver.java:

protected void extractFile( final File srcF, final File dir, final InputStream compressedInputStream, String entryName, final Date entryDate, final boolean isDirectory, final Integer mode, String symlinkDestination, final FileMapper[] fileMappers)
    throws IOException, ArchiverException
    {
        ...
        // Hmm. Symlinks re-evaluate back to the original file here. Unsure if this is a good thing...
        final File targetFileName = FileUtils.resolveFile( dir, entryName );


        // Make sure that the resolved path of the extracted file doesn't escape the destination directory
        // getCanonicalFile().toPath() is used instead of getCanonicalPath() (returns String),
        // because "/opt/directory".startsWith("/opt/dir") would return false negative.
        Path canonicalDirPath = dir.getCanonicalFile().toPath();
        Path canonicalDestPath = targetFileName.getCanonicalFile().toPath();


        if ( !canonicalDestPath.startsWith( canonicalDirPath ) )
        {
            throw new ArchiverException( "Entry is outside of the target directory (" + entryName + ")" );
        }


        try
        {
            ...
            if ( !StringUtils.isEmpty( symlinkDestination ) )
            {
                SymlinkUtils.createSymbolicLink( targetFileName, new File( symlinkDestination ) );
            }
            else if ( isDirectory )
            {
                targetFileName.mkdirs();
            }
            else
            {
                try ( OutputStream out = Files.newOutputStream( targetFileName.toPath() ) )
                {
                    IOUtil.copy( compressedInputStream, out );
                }
            }


            targetFileName.setLastModified( entryDate.getTime() );


            if ( !isIgnorePermissions() && mode != null && !isDirectory )
            {
                ArchiveEntryUtils.chmod( targetFileName, mode );
            }
        }
        catch ( final FileNotFoundException ex )
        {
            getLogger().warn( "Unable to expand to file " + targetFileName.getPath() );
        }
    }

When given an entry that already exists in dir as a symbolic link whose target does not exist - the symbolic link’s target will be created and the content of the archive’s entry will be written to it.

That’s because the way FileUtils.resolveFile() works:

public static File resolveFile( final File baseFile, String filename )
    {
        ...
        try
        {
            file = file.getCanonicalFile();
        }
        catch ( final IOException ioe )
        {
            // nop
        }


        return file;
    }

File.getCanonicalFile() (tested with the most recent version of openjdk (22.2) on Unix) will eventually call JDK_Canonicalize():

JNIEXPORT int
JDK_Canonicalize(const char *orig, char *out, int len)
{
    if (len < PATH_MAX) {
       …

The Plexus project provides a full software stack for creating and executing software projects. It provides a number of pre-built components for common tasks and toolkits such as Jetty, Velocity, Hibernate, i18n, and many more. However, Plexus is also able to reuse your existing components written for other IoC frameworks such as Spring, Avalon and Pico Container unmodified, as well as allowing you to reuse your existing code inside the Plexus Container.

Security Fix(es):

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.(CVE-2023-37460)

The Plexus project provides a full software stack for creating and executing software projects. It provides a number of pre-built components for common tasks and toolkits such as Jetty, Velocity, Hibernate, i18n, and many more. However, Plexus is also able to reuse your existing components written for other IoC frameworks such as Spring, Avalon and Pico Container unmodified, as well as allowing you to reuse your existing code inside the Plexus Container.

Security Fix(es):

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.(CVE-2023-37460)

The Plexus project provides a full software stack for creating and executing software projects. It provides a number of pre-built components for common tasks and toolkits such as Jetty, Velocity, Hibernate, i18n, and many more. However, Plexus is also able to reuse your existing components written for other IoC frameworks such as Spring, Avalon and Pico Container unmodified, as well as allowing you to reuse your existing code inside the Plexus Container.

Security Fix(es):

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.(CVE-2023-37460)

The Plexus project provides a full software stack for creating and executing software projects. It provides a number of pre-built components for common tasks and toolkits such as Jetty, Velocity, Hibernate, i18n, and many more. However, Plexus is also able to reuse your existing components written for other IoC frameworks such as Spring, Avalon and Pico Container unmodified, as well as allowing you to reuse your existing code inside the Plexus Container.

Security Fix(es):

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.(CVE-2023-37460)

The Plexus project provides a full software stack for creating and executing software projects. It provides a number of pre-built components for common tasks and toolkits such as Jetty, Velocity, Hibernate, i18n, and many more. However, Plexus is also able to reuse your existing components written for other IoC frameworks such as Spring, Avalon and Pico Container unmodified, as well as allowing you to reuse your existing code inside the Plexus Container.

Security Fix(es):

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.(CVE-2023-37460)

The Plexus project provides a full software stack for creating and executing software projects. It provides a number of pre-built components for common tasks and toolkits such as Jetty, Velocity, Hibernate, i18n, and many more. However, Plexus is also able to reuse your existing components written for other IoC frameworks such as Spring, Avalon and Pico Container unmodified, as well as allowing you to reuse your existing code inside the Plexus Container.

Security Fix(es):

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.(CVE-2023-37460)

Plexis Archiver is a collection of Plexus components to create archives or extract archives to a directory with a unified Archiver/UnArchiver API. Prior to version 4.8.0, using AbstractUnArchiver for extracting an archive might lead to an arbitrary file creation and possibly remote code execution. When extracting an archive with an entry that already exists in the destination directory as a symbolic link whose target does not exist - the resolveFile() function will return the symlink's source instead of its target, which will pass the verification that ensures the file will not be extracted outside of the destination directory. Later Files.newOutputStream(), that follows symlinks by default, will actually write the entry's content to the symlink's target. Whoever uses plexus archiver to extract an untrusted archive is vulnerable to an arbitrary file creation and possibly remote code execution. Version 4.8.0 contains a patch for this issue.

These are all security issues fixed in the plexus-archiver-4.8.0-2.1 package on the GA media of openSUSE Tumbleweed.

This update for Java fixes the following issues:

plexus-archiver was updated from version 4.2.1 to 4.8.0:

• Changes of 4.8.0:

  • Security issues fixed:

    • CVE-2023-37460: Avoid override target symlink by standard file in AbstractUnArchiver (bsc#1215973)

  • New features and improvements:

    • Added tzst alias for tar.zst archiver/unarchived

  • Bugs fixed:

    • Detect permissions for addFile

  • Maintenance:

    • Removed public modifier from JUnit 5 tests
    • Use https in scm/url
    • Removed junit-jupiter-engine from project dependencies
    • Removed parent and reports menu from site
    • Cleanup after 'veryLargeJar' test
    • Override project.url

• Changes of 4.7.1:

  • Bugs fixed:

    • Don't apply umask on unknown perms (Win)

• Changes of 4.7.0:

  • New features and improvements:

    • add umask support and use 022 in RB mode
    • Use NIO Files for creating temporary files
    • Deprecate the JAR Index feature (JDK-8302819)
    • Added Archiver aliases for tar.*

  • Maintenance:

    • Use JUnit TempDir to manage temporary files in tests
    • Override uId and gId for Tar in test
    • Bump maven-resources-plugin from 2.7 to 3.3.1

• Changes of 4.6.3:

  • New features and improvements:

    • Fixed path traversal vulnerability The vulnerability affects only directories whose name begins with the same prefix as the destination directory. For example malicious archive may extract file in /opt/directory instead of /opt/dir.

• Changes of 4.6.2:

  • Bugs fixed:

    • Fixed regression in handling symbolic links

• Changes of 4.6.1:

  • Bugs fixed:

    • Normalize file separators before warning about equal archive entries

• Changes of 4.6.0:

  • New features and improvements:

    • keep file/directory permissions in Reproducible Builds mode

• Changes of 4.5.0:

  • New features and improvements:

    • Added zstd (un)archiver support

  • Bugs fixed:

    • Fixed UnArchiver#isOverwrite not working as expected

• Changes of 4.4.0:

  • New features and improvements:

    • Drop legacy plexus API and use only JSR330 components

• Changes of 4.3.0:

  • New features and improvements:

    • Require Java 8
    • Refactor to use FileTime API
    • Rename setTime method to setZipEntryTime
    • Convert InputStreamSupplier to lambdas

  • Bugs fixed:

    • Reproducible Builds not working when using modular jar

• Changes of 4.2.7:

  • New features and improvements:

    • Respect order of META-INF/ and META-INF/MANIFEST.MF entries in a JAR file

• Changes of 4.2.6:

  • New features and improvements:

    • FileInputStream, FileOutputStream, FileReader and FileWriter are no longer used
    • Code cleanup

• Changes of 4.2.5:

  • New features and improvements:

    • Speed improvements

  • Bugs fixed:

    • Fixed use of a mismatching Unicode path extra field in zip unarchiving

• Changes of 4.2.4:

  • Bugs fixed:

    • Fixed unjustified warning about casing for directory entries

• Changes of 4.2.2:

  • Bugs fixed:

    • DirectoryArchiver fails for symlinks if a parent directory doesn't exist

objectweb-asm was updated to version 9.6:

• Changes of version 9.6:

  • New Opcodes.V22 constant for Java 22

  • Bugs fixed:

    • Analyzer produces frames that have different locals than those detected by JRE bytecode verifier
    • Invalid stackmap generated when the instruction stream has new instruction after invokespecial to <init>
    • Analyzer can fail to catch thrown exceptions
    • asm-analysis Frame allocates an array unnecessarily inside executeInvokeInsn
    • Fixed bug in CheckFrameAnalyzer with static methods

• Changes of version 9.5:

  • New Opcodes.V21 constant for Java 21

  • New readBytecodeInstructionOffset hook in ClassReader

  • Added more detailed exception messages

  • Javadoc improvements and fixes

  • Bugs fixed:

    • Silent removal of zero-valued entries from the line-number table

• Changes of version 9.4:

  • Changes:

    • New…