Bugzilla – Bug 62537
VUL-0: CVE-2004-0916: directory traversal bug in cabextract
Last modified: 2021-11-02 16:04:24 UTC
We received the following report via vendor-sec. The issue is public. Date: Fri, 22 Oct 2004 09:01:11 +0200 From: Martin Schulze <joey@infodrom.org> To: vendor-sec@lst.de Subject: [vendor-sec] CAN-2004-0916: directory traversal in cabextract Hi, not sure if one of you ships cabextract (to extract M$ .cab files) as well. The upstream developers have discovered that the program was able to overwrite files in upper directory level. The standard missing "../" sanitising. Patch attached. This issue is already public. --- cabextract.c 6 Mar 2001 16:27:43 -0000 1.1.1.1 +++ cabextract.c 20 Oct 2004 19:15:58 -0000 1.1.1.1.2.2 if (*p=='/') *p='\\'; else if (*p=='\\') *p='/'; } + /* search for "../" in cab filename part and change to "xx/". This + * prevents any unintended directory traversal. */ + for (p = fi->filename; *p; p++) { + if ((p[0] == '.') && (p[1] == '.') && (p[2] == '/')) { + p[0] = p[1] = 'x'; + p += 2; + } + } + if (ensure_filepath(fi->filename)) { fi->fh = fopen(fi->filename, "wb"); if (fi->fh) ok = 1; Regards, Joey
Against which cabextract version is this? I cannot find this context in cabextract 1.0 at all. There is something in cabextract 0.6, which looks similar to the context above. This needs to be investigated by the security team. BTW, we use cabextract 1.0 for 9.1/SLES9, 9.2 and cabextract 0.6 for 8.2 and 9.0 (new package since 8.2).
The latest version is 1.1. The security issue seems to be fixed in 1.1. http://www.kyz.uklinux.net/cabextract.php [...] Changes since cabextract 1.0 - A security vulnerability has been fixed. If the files within a cabinet file include "../" in their filenames, this will be changed to "xx/", so cabinets cannot access the parent directory of where you want to extract them.
BTW, I would like to know, why it is a security problem to extract something in "..". Don't I always list the content of a .cab file before extracting it to make sure no files are overwritten? Where is the big difference between overwriting some file in "." and ".." ?
Created attachment 25393 [details] cabextract-0.6.diff
Created attachment 25394 [details] cabextract-1.0.diff
submitted cabextract-1.1, which already fixes this issue (see comment #2), now for STABLE. It needs to be decided if a security update for older version is required. I already attached the patches for 0.6 and 1.0.
you can chain multiple ".." to overwrite any file on the system belonging to the user ... like ../../../etc/passwd or so which is the usual problem.
OK. So other archive tools like tar/zip don't suffer from this problem, right? sndirsch@shannon:~/tmp> tar cvf simple.tar ../selection tar: Removing leading `../' from member names ../selection sndirsch@shannon:~/tmp> tar tvf simple.tar -rw-r--r-- sndirsch/suse 22480 2004-10-26 05:54:27 selection sndirsch@shannon:~/tmp> zip simple.zip ../selection adding: ../selection (deflated 62%) sndirsch@shannon:~/tmp> unzip -v simple.zip Archive: simple.zip Length Method Size Ratio Date Time CRC-32 Name -------- ------ ------- ----- ---- ---- ------ ---- 22480 Defl:N 8545 62% 10-26-04 05:54 2ede8e2e ../selection -------- ------- --- ------- 22480 8545 62% 1 file sndirsch@shannon:~/tmp> unzip simple.zip Archive: simple.zip warning: skipped "../" path component(s) in ../selection inflating: selection sndirsch@shannon:~/tmp>
for most of those this problem has been fixed already (but was present in the past) (namely "zip", "lha" and most likely "tar" too). we currently still have it open for "zoo" and "unarj".
Ok. The question is, will we need a security update for older distributions or was it sufficient to fix it for STABLE.
i think cabextract and this issue are not of that large importance. a fix for STABLE is enough in this case.
> ... a fix for STABLE is enough in this case. which I already submitted and was checked in this morning. FIXED. :-)
CVE-2004-0916: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:P/A:N)