GNOME Bugzilla – Bug 698554
file-roller deletes the content of folders upon extraction, if archive contains links
Last modified: 2016-09-08 14:14:59 UTC
This may be a duplicate of bug 647753 but I'm not entirely sure, its description isn't crystal-clear. I also reported this bug on launchpad : https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1171236 Package : file-roller 3.6.1.1-0ubuntu1.1 os : ubuntu 12.10 x64 partition format: ext4 Description : ============= When extracting a zip archive containing links to folders (instead of "real" folders), if the hard drive where the archive is extracted contains folders named like those contained in the archive (no matter their location), their content will be erased. The files erased are not in the dustbin, they just disappear. Expected behavior : =================== When creating an archive from links to folders, I would expect the "real" folders to be added to the archive. And upon extraction, I would expect them not to be emptied ! Steps to reproduce the bug : ============================ 1- Create a folder, say "container" 2- Inside, create another folder, say "real folder" 3- Place some files inside this folder (say a week worth of precious work for instance. ah ah!) 4- Create a link of this folder in nautilus (right clic -> create a link) It should look like this : -container |_real folder (with files inside) |_link to real folder 5- Create an archive from "link to real folder" (a zip in my test) 6- Extract that archive anywhere you want. You will get an error message saying the files could not be extracted. Check "real folder" : all the files should have disappeared ! Another thing to note : I works from one computer to another. Create a "bogus" archive in computer A, extract it in computer B. If computer B happens to have the same folders as the links contained inside the archive, they will also be emptied.
... just happened similar thing/bug also with file-roller 3.20.2!!! and gnome 3.20.2 on Archlinux 64bit Note for file-roller devs : let me know if it is better open a new bug report for file-roller 3.20.x regarding this issue... btw, try to explain better what happened.. Today I opened a not recent backup.tar.gz with file-roller 3.20.3 which contain backupped folders . Into some folder are present some symbolic links Links was \home\myaccount\Documents >> \home\public\Documents \home\myaccount\Music >> \home\public\Music \home\myaccount\Pictures >> \home\public\Pictures \home\myaccount\Videos >> \home\public\Videos Then I clicked to Documents symbolic link file-roller opened a second session and showed me files in the real folder on hard drive (I guess...) Then I close all file-roller and noticed that suddenly wallpaper disappeared (mhh really strange ... ;-) A quick check and sadly discovered that real folder \home\public was empty : all files and folders gone!!!! Fortunatelly I have another recent backup but this bug is really dangerous..
The problem was caused by symbolic links pointing to absolute paths, this is now fixed in the current development version, the fix will be available in the next stable release (3.20.3) and higher versions. Thank you for the bug reports.
Created attachment 335039 [details] Test archive for testing this bug in File Roller I initially had some trouble understanding the security impact of this bug due to the reproducer instructions mixing the setup (creating the archive) with instructions for triggering the flaw (extracting the archive). I'll attempt to improve on the instructions by attaching a previously created archive. = Setup = Create /dev/shm/will-be-emptied/important.txt which will act as an important file that we wouldn't want to lose. $ mkdir -p /dev/shm/will-be-emptied/ $ echo data > /dev/shm/will-be-emptied/important.txt = Test = 1. Open the attached links.tar with File Roller $ file-roller links.tar 2. Double-click either of the "absolute" or "relative" files 3. Close the opened Nautilus window as well as the File Roller window 4. Check to see if /dev/shm/will-be-emptied/important.txt has been unintentionally deleted If a user was tricked into opening a crafted archive containing a malicious symlink target, File Roller could remove unintended files when cleaning up the temporary cache directory. This bug was introduced in File Roller 3.5.4 by the following commit: commit 34b64f3a897c4b4e8e180c028f326bc921eb08ec Date: Sun Aug 5 21:04:47 2012 +0200 use GFile instead of 'char *' It was fixed in File Roller 3.20.3 by the following commit: commit f70be1f41688859ec8dbe266df35a1839ceb96c5 Date: Wed Aug 17 15:41:35 2016 +0200 do not follow symlinks when deleting a folder recursively I will request a CVE on the oss-security list and update this bug when one has been assigned.
(In reply to Paolo Bacchilega from comment #2) > The problem was caused by symbolic links pointing to absolute paths Relative symlink targets also triggered the bug. Either of these files in the attached links.tar are sufficient: $ tar tvf links.tar lrwxrwxrwx tyhicks/tyhicks 0 2016-09-07 17:04 absolute -> /dev/shm/will-be-emptied/ lrwxrwxrwx tyhicks/tyhicks 0 2016-09-07 17:04 relative -> ../../../../../../../../../../../../../../../../../../../../../../../../../dev/shm/will-be-emptied/
CVE-2016-7162 http://openwall.com/lists/oss-security/2016/09/08/4