Probable exploitable path construction in CsvDataSource.java

[iSnow]

Overview

Problem Description

I believe there is a path construction weakness in CsvDataSource that can be exploited by a malicious DataPackage. It would be exploitable in a server setting where users can upload DataPackages and browse through the linked resources. Consequences would be data exfiltration of well-known system configuration files.

CsvDataSource reads and returns CSV files linked as resources. In getCSVParser(), it does the following:

       // The path value can either be a relative path or a full path.
        // If it's a relative path then build the full path by using the working directory.
        File f = (File)this.dataSource;
        if(!f.exists()) { 
            f = new File(System.getProperty("user.dir") + "/" + f.getAbsolutePath());
        }

        // Read the file.
        Reader fr = new FileReader(f);

        // Get the parser.
        return CSVFormat.RFC4180.withHeader().parse(fr);

If a malicious DataPackage has a resource link like "/etc/passwd", it would be regarded as an absolute path, the check for existence would be true and the file contents would be returned (I believe /etc/passwd could be read as CSV with the right dialect settings, and others like an fstab file on Linux most certainly as well).

Problem Resolution

Absolute paths need to be disallowed for resources

Ideally, there would be a two-prong approach:

• Check paths while reading from the resources entry of the package descriptor file ("datapackage.json") and filter out absolute paths or make them relative to the package descriptor file, disallowing paths construction outside of datapackage.json's directory

• in CsvDataSource, the file needs to be made relative to the package descriptor file (in case someone uses the library outside of datapackage-java) again.

---

Please preserve this line to notify @georgeslabreche (lead of this repository).

@roll I don't think the tableschema-java lib is in widespread use, but this needs to be tackled. Also, other implementations might want to ensure they are handling malicious DataPackages like this well.

[roll]

@iSnow Good catch. Relative paths were prohibited in the specs in the middle of the work on the library I think. Now it says:

SECURITY: / (absolute path) and ../ (relative parent path) are forbidden to avoid security vulnerabilities when implementing data package software. These limitations on resource path ensure that resource paths only point to files within the data package directory and its subdirectories. This prevents data package software being exploited by a malicious user to gain unintended access to sensitive information.

[iSnow]

Fix: https://github.com/frictionlessdata/tableschema-java/pull/32

[iSnow]

Fixed and added to the documentation at http://frictionlessdata.io/specs/data-resource/index.html#url-or-path