After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 794337 - Path traversal vulnerability
Path traversal vulnerability
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: file-roller-maint
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2018-03-14 20:44 UTC by Warsocket
Modified: 2019-09-22 11:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
poc video and tarball (3.51 MB, application/gzip)
2018-03-15 06:56 UTC, Warsocket
Details

Description Warsocket 2018-03-14 20:44:01 UTC
While dragging a specific file / map to a location to extract to, a single ./../ path traversal is possible if present in the tar file.

Demo video also shows that the default tar command does not allow this.

Also the extract button option for the whole of the file also does not exert this behaviour.

The video and the POC tarball from the demo are added in a tarball :P (just a normal tarball this time yes)

Set Severity to normal due to the fact that you still get a correct, albeit confusing, statement about overwriting files.
Comment 1 Warsocket 2018-03-15 06:56:09 UTC
Created attachment 369703 [details]
poc video and tarball
Comment 2 Warsocket 2018-04-24 16:05:28 UTC
Does nobody care about this security issue?
This issue has been open for over a month without any progress, I doubt anyone has even read it.

The one level path traversal can be used for some malicious stuff.
EG: You could seed a home directory with your own .ssh/authorized_keys file/map, by having a user extract a map to their home directory.
Comment 3 Paolo Bacchilega 2018-07-15 08:29:50 UTC
So how to fix this?  Should we just ignore filenames that contains '..' ?
Comment 4 Warsocket 2018-07-18 05:46:32 UTC
Ignoring the filing with path containing .. or stripping out the (..) parts of the path will both do.

I would prefer ignoring the files since that more robust and less prone to error, however but stripping out the .. part seems more in-line with the current workings.

(This is because a simple ../x file will just be extracted as x, but an ./../x will perform path traversal. So removing the the relative .. parts of the path will be more consistent with currenct behaviour )
Comment 5 Paolo Bacchilega 2018-08-27 13:19:48 UTC
Fixed ignoring the files with relative paths. 

(commit 57268e51e59b61c9e3125eb0f65551c7084297e2)
Comment 6 Alex Murray 2018-09-17 14:49:09 UTC
Has a CVE been assigned to track this vulnerability? If not, can one please be applied for https://cve.mitre.org/cve/request_id.html
Comment 7 Warsocket 2019-09-21 19:03:21 UTC
Since nothing seemed to be happening CVE wise I just filed an request for an CVE-id.

Fitst time I've done so, so hope it does not get stuck in bureaucratics.
Comment 8 Warsocket 2019-09-22 11:19:55 UTC
Apparently getting a CVE number was not that hard:
CVE-2019-16680 has been issued for this vulnerability