Reposilite vulnerable to path traversal while serving javadoc expanded files (arbitrary file read) (`GHSL-2024-074`)

Summary

### Summary Reposilite v3.5.10 is affected by an Arbitrary File Read vulnerability via path traversal while serving expanded javadoc files. ### Details The problem lies in the way how the expanded javadoc files are served. The `GET /javadoc/{repository}/<gav>/raw/<resource>` route uses the `<resource>` path parameter to find the file in the `javadocUnpackPath` directory and returns it's content to the user. [JavadocFacade.kt#L77](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocFacade.kt#L77): ```kotlin fun findRawJavadocResource(request: JavadocRawRequest): Result<JavadocRawResponse, ErrorResponse> = with (request) { mavenFacade.canAccessResource(accessToken, repository, gav) .flatMap { javadocContainerService.loadContainer(accessToken, repository, gav) } .filter({ Files.exists(it.javadocUnpackPath.resolve(resource.toString())) }, { notFound("Resource $resource not found") }) .map { JavadocRawResponse( contentType = supportedExtensions[resource.getExtension()] ?: ContentType.APPLICATION_OCTET_STREAM, content = Files.newInputStream(it.javadocUnpackPath.resolve(resource.toString())) ) } } ``` In this case, the `<resource>` path parameter can contain path traversal characters such as `/../../`. Since the path is concatenated with the main directory, it opens the possibility to read files outside the `javadocUnpackPath` directory. #### Impact This issue may lead to Arbitrary File Read on the server. A potential attacker can read some sensitive file, such as `reposilite.db`, that contains the sqlite database used by Reposilite. This database contains the sensitive information used by Reposilite, including passwords and hashes of issued tokens. Also, the `configuration.cdn` file can be read, which contains other sensitive properties. ### Steps to reproduce 1. Start the Reposilite instance on http://localhost:8080/ 2. Find at least one javadoc file in the hosted repositories. For example, the default test workspace contains the `/releases/javadoc/1.0.0/javadoc-1.0.0-javadoc.jar` archive that is suitable for our attack. 3. Send a GET request to http://127.0.0.1:8080/javadoc/releases/javadoc/1.0.0/raw/%2e%2e%5c%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2freposilite.db When this request is processed on the server, Reposilite tries to unpack the `/repositories/releases/javadoc/1.0.0/javadoc-1.0.0-javadoc.jar` file into the `/javadocs/releases/javadoc/1.0.0/.cache/unpack` folder. Then, it tries to read the `../../../../../../reposilite.db` file from this folder, which triggers the path traversal attack.  ### Remediation Normalize (remove all occurrences of `/../`) the `<resource>` path parameter before using it when reading the file. For example: ```kotlin content = Files.newInputStream(it.javadocUnpackPath.resolve(resource.toPath())) ``` Changing `resource.toString()` to `resource.toPath()` is enough here as the `com.reposilite.storage.api.Location#toPath` method normalizes the string internally.