TITLE: Unarj Directory Traversal Vulnerability SECUNIA ADVISORY ID: SA12788 VERIFY ADVISORY: http://secunia.com/advisories/12788/ CRITICAL: Less critical IMPACT: System access WHERE: From remote SOFTWARE: unarj 2.x http://secunia.com/product/4036/ DESCRIPTION: Doubles has reported a vulnerability in Unarj, which potentially can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to an input validation error when unpacking archives. This can be exploited via a directory traversal attack to overwrite files outside the directory, where the files are extracted to, if a user is tricked into extracting a malicious archive using Unarj. Successful exploitation requires that the "x" option is used to preserve paths. The vulnerability has been confirmed in version 2.63 and has also been reported in version 2.65. Other versions may also be affected. SOLUTION: Don't use Unarj with the "x" option to preserve paths on archived files, which are not fully trusted. Never unpack archives as "root" or another administrative user. PROVIDED AND/OR DISCOVERED BY: Doubles
Sent upstream an email regarding this issue. I will be awaiting a response before we take any formal action.
hi, somehow i don't understand this bug... ;-) according to mailing list, the reporter extracted the archive as 'root' and root, yes, has the power to write everywhere. basically i can create a tar archive with full path and tar will happily overwrite my whole system too... ;-) --quote from bugtraq -- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Umphress wrote: >>>>...somehow i don't expect programs to mess with /usr. not as a user and >>>>not as root. > >> >> I just picked /usr, it could have been /etc, /var or any other >> standard directory that every *nix distribution has. Regardless, if I >> try to make unarj write to a directory that I don't have the >> neccessary permissions for, it asks me to pick an alternate location >> to extract to. yes, but this is the point! when i happen to unarj a package with the unarj version you have as user "root", then unarj *will* have the permission to overwrite /etc or whatever. it won't kindly ask but just overwrite, or does it? (you've shown unarj in action with sudo when test.txt was non-existant). - -- BOFH excuse #290: The CPU has shifted, and become decentralized. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBa8XFC/PVm5+NVoYRAonoAKCGvDw7nWPHmeiSLbIJnZTZL96DrQCgyzVp 2Nj8WyhvyAGZWdyR6ce9W/s= =4bNP -----END PGP SIGNATURE----- _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html --------------------------------------------------------------------------- >yes, but this is the point! when i happen to unarj a package with the >> unarj version you have as user "root", then unarj *will* have the >> permission to overwrite /etc or whatever. it won't kindly ask but just >> overwrite, or does it? (you've shown unarj in action with sudo when >> test.txt was non-existant). arj does ask if you want to overwrite an existing file. --------------- snip ---------------- chris@chris:/home$ ls -l /usr/local/bin/test.txt /usr/bin/ls: /usr/local/bin/test.txt: No such file or directory chris@chris:/home$ ./chris/test/arj x chris/test/test.arj ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia. [11 Oct 2004] Processing archive: chris/test/test.arj Archive created: 2004-10-11 12:22:42, modified: 2004-10-11 12:22:42 Error (13): Permission denied Can't open ../usr/local/bin/test.txt OK to extract to a new filename? Break signaled! chris@chris:/home$ sudo ./chris/test/arj x chris/test/test.arj ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia. [11 Oct 2004] Processing archive: chris/test/test.arj Archive created: 2004-10-11 12:22:42, modified: 2004-10-11 12:22:42 Extracting ../../usr/local/bin/test.txt to ../usr/local/bin/test.txt OK 1 file(s) chris@chris:/home$ sudo ./chris/test/arj x chris/test/test.arj ARJ32 v 3.10, Copyright (c) 1998-2004, ARJ Software Russia. [11 Oct 2004] Processing archive: chris/test/test.arj Archive created: 2004-10-11 12:22:42, modified: 2004-10-11 12:22:42 ARJ 13 04-10-11 12:21:48, DISK 13 04-10-11 12:21:48 ../usr/local/bin/test.txt is same or newer, Overwrite? Break signaled! chris@chris:/home$ ls -l /usr/local/bin/test.txt -rw-r--r-- 1 root root 13 2004-10-11 12:21 /usr/local/bin/test.txt -------------------------------------- -- end quote -- i don't know... does not look like a real vuln for me, IHMO ;-) best regards florian [rootshell]
I think it's completely bogus. If I run as root and ask ARJ to preserve in-archive directory names, it's logical it will overwrite anything. lewk: unconfirmed bugs should stay in NEW status...
Yeah, this looks bogus, but I will wait for upstream to respond (or not respond) to close this. There is also a discussion regarding this issue on full-disclosure.
Here is the response from upstream: === Hello, Thank you for your question about UNARJ and thank you for pointing out the advisory. We have never recommended that UNARJ (free extraction source code example) be used in a production environment. It was released to demonstrate how to build a true ARJ archive extracting program. It is missing a lot of essential / desired features to become a full scale program. We purposely limited its functionality to encourage users to BUY our ARJ.EXE program for extraction work. UNARJ was provided to give users a limited sense of comfort in terms of not having to rely SOLELY on our production program. A user does not want to see their data locked forever in a data archive because the only extraction program stopped working. Obviously, a barely functional demonstration program would have a LOT of bugs and buffer overflow situations that could be exploited by others especially with the source code fully revealed. In your place, I would either use the full powered ARJ.EXE (shareware) or rewrite UNARJ and build your own version of UNARJ with the fixes desired. Regards, Robert Jung === Security, what do you guys think?
Closing because it is a bogus vulnerability.
*** Bug 67342 has been marked as a duplicate of this bug. ***
