Application code is getting a file from the root path, allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

[dionmcm]

amt-flat-file-generator-master\amt-flat-file-generator-master\src\main\java\au\gov\digitalhealth\terminology\amtflatfile\AmtCache.java, 56

Observation: Application code is getting a file from the root path, allowing user input to control paths used in file system operations could enable an attacker to access or modify otherwise protected system resources.

Risk: In application code directly embedding a file name or a path for the file name in the program to access the system resources could be cleverly exploited by a malicious user who may pass an unexpected value for the argument and the consequences of executing the program, especially if it runs with elevated privileges, with that argument may turn out to be fatal. Thus, Path Manipulation vulnerability is a very serious issue and should be definitely not left unattended in a code. Such a vulnerability may enable an attacker to access or modify otherwise protected system resources.

The best way to prevent path manipulation is with a level of indirection: create a list of legitimate resource  names that a user is allowed to specify, and only allow the user to select from the list. With this approach the input provided by the user is never used directly to specify the resource name. In some situations this approach is impractical because the set of legitimate resource names is too large or too hard to keep track of.

A better approach is to create a whitelist of characters that are allowed to appear in the resource name and accept input composed exclusively of characters in the approved set.

[dionmcm]

Raised based on feedback from a vendor security review

[dionmcm]

The application code is scanning a zip file provided to it as a FileSystem object, looking for specific files in the supplied zip known to SNOMED CT-AU RF2 release files by name. The calling code completely controls the FileSystem object that is passed in, and in the case of this code the Amt2FlatFile class passes in a FileSystem created from a ZIP file. The code only has access to the content of the zip file, and is scanning the ZIP file from it’s root. If the calling code had an exploded zip file it could pass a FileSystem object rooted at the location the ZIP file was extracted.

Practically, no path manipulation is possible. The suggested mitigation is already implemented – the FileSystem object passed to the class is scanned by the TerminologyFileVisitor class, which looks for specific files by name pattern in the ZipFileSystem passed in, and only acts on those files found matching that pattern. The line referenced represents that scanning occurring from the root of the ZipFileSystem passed in.

The calling code is in complete control of the FileSystem object passed in and its contents, however the code is limited to look for the specific RF2 files by name pattern required by the application.