Coordinated Disclosure Timeline
- 2023-04-12: Reported vulnerability via GitHub’s private vulnerability reporting feature.
- 2023-05-21 Vulnerabilities were fixed and advisories were published 1, 2.
Summary
Two Tar Slip vulnerabilities were found in Autolab. Those vulnerabilities could have allowed attackers to create or replace files on the file system that in the worst case could have been executed by the application or system itself.
Product
Autolab
Tested Version
Details
Issue 1: Tar slip in Install Assessment functionality (GHSL-2023-081)
A Tar slip vulnerability was found in the Install assessment functionality of Autolab. To exploit this vulnerability an authenticated attacker with instructor permissions needs to upload a specially crafted Tar file.
Using the install assessment functionality an attacker can feed a Tar file that contain files with paths pointing outside of the target directory (e.g., ../../../../tmp/tarslipped1.sh). When the Install assessment form is submitted the files inside of the archives are expanded to the attacker-chosen locations.
Following line inside the method importAsmtFromTar writes the file to the destination defined by the attacker:
File.open(File.join(course_root, relative_pathname), "wb") do |f|
This relative_pathname variable uses the full_name retrieved from the archive.
relative_pathname = entry.full_name
This vulnerability was discovered with the help of CodeQL.
Proof of Concept
Preconditions:
- Attacker needs to be logged in as instructor
- There needs to be an existing course where the instructor has access permissions
The attacker can then visit the following link in the browser to install an assessment:
https://<autolab-host>/courses/<course-slug>/assessments/install_assessment
On this page the attacker can specify a specially crafted tar ball (see exploitlab.tar in Resources) in the “Import from tarball” section.
After selecting the malicious tar ball the form is submitted and the tar ball unzipped.
In the case of a successful exploitation, a file named tarslipped1.sh should appear in the /tmp folder of the exploited system.
Impact
This issue may lead to arbitrary file write. It may lead up to Remote Code Execution if it’s possible to write to a file which is later executed.
Resources
To reproduce the vulnerability a tar archive of an existing assessment can be extended as follows:
- Create a file in
/tmp/:
touch /tmp/tarslipped1.sh
- Append the newly created file to the existing assessment tar archive (named
exploitlab.tar):tar -rf exploitlab.tar ../../../../../../../../tmp/tarslipped1.sh
Issue 2: Tar slip in cheat checker functionality (GHSL-2023-082)
A Tar slip vulnerability was found in the MOSS cheat checker functionality of Autolab. To exploit this vulnerability an authenticated attacker with instructor permissions needs to upload a specially crafted Tar file. Both “Base File Tar” and “Additional file archive” can be fed with Tar files that contain paths outside their target directories (e.g., ../../../../tmp/tarslipped2.sh). When the MOSS cheat checker is started the files inside of the archives are expanded to the attacker-chosen locations.
Following line inside the method extract_tar_for_moss writes the file to the destination defined by the attacker:
File.open(destination, "wb") do |out|
This destination variable uses the pathname retrieved from the archive.
pathname = Archive.get_entry_name(entry)
It looks like the same method contains a sanitizer of sorts that might have been intended to prevent such scenarios:
pathname.gsub!(%r{/}, "-")
Unfortunately, the variable pathname is not used anymore after this line.
This vulnerability was discovered with the help of CodeQL.
Proof of Concept
Preconditions:
- Attacker needs to be logged in as instructor
- There needs to be an existing course where the instructor has access permissions
The attacker can then visit the following in the browser to run the MOSS cheat checker:
https://<autolab-host>/courses/<course-slug>/moss
On this page the attacker can specify a specially crafted tar ball (see tarslip.tar in Resources). The Tar ball can either be submitted under “Step 2” as “Base file” (“Base File tar” needs to be enabled as well) or under “Step 3” as “Additional file archive”.
After specifying a malicious tar ball the attacker can submit the form by clicking on “GO!”.
In the case of a successful exploitation, a file named tarslipped2.sh should appear in the /tmp folder of the exploited system.
Impact
This issue may lead to arbitrary file write. It may lead up to Remote Code Execution if it’s possible to write to a file which is later executed.
Resources
To reproduce the vulnerability a tar archive can be created as follows:
- Create a file in
/tmp/:
touch /tmp/tarslipped2.sh
- Create a tar file:
tar -cvf tarslip.tar ../../../../../../../../tmp/tarslipped2.sh
In the case of a successful exploitation, a file named tarslipped2.sh should appear in the /tmp folder of the exploited system.
CVE
- CVE-2023-32676 Tar slip in Install Assessment functionality
- CVE-2023-32317 Tar slip in cheat checker functionality
Credit
These issues were discovered and reported by GHSL team member @p- (Peter Stöckli).
Contact
You can contact the GHSL team at securitylab@github.com, please include a reference to GHSL-2023-081 or GHSL-2023-082 in any communication regarding these issues.