Common Vulnerabilities and Exposures assigned an identifier CVE-2012-4024 to the following vulnerability: Name: CVE-2012-4024 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4024 Assigned: 20120716 Reference: http://sourceforge.net/mailarchive/forum.php?thread_name=CAAoG81HL9oP8roPLLhftTSXTzSD%2BZcR66PRkVU%3Df76W3Mjde_w%40mail.gmail.com&forum_name=squashfs-devel Reference: http://www.osvdb.org/83898 Stack-based buffer overflow in the get_component function in unsquashfs.c in unsquashfs in Squashfs 4.2 and earlier allows remote attackers to execute arbitrary code via a crafted list file (aka a crafted file for the -ef option). NOTE: probably in most cases, the list file is a trusted file constructed by the program's user; however, there are some realistic situations in which a list file would be obtained from an untrusted remote source. Also some additional notes from MITRE [1]: Although Squashfs is a Linux filesystem, these two CVEs are about a utility program that is, in some ways, similar to tar or other archive programs. In general, if an archive file might be obtained from an untrusted remote source, and crafted data within the archive file potentially leads to arbitrary code execution during extraction, the issue can be included in CVE. There are many CVEs in this category (e.g., see CVE-2011-1777 and CVE-2011-1778 in RHSA-2011:1507-1). CVE-2012-4025 also fits into this category. CVE-2012-4024 is different because the crafted data isn't in the archive file. Specifically, the crafted data must be in a list file that's similar to the list file used with the "tar -T" option. One threat model is that an attacker announces 'We have created an example of our project as a squashfs filesystem. The downloadable files are myproject.sqsh and myproject.list. If you only want the source code, you can extract it by running the "unsquashfs myproject.sqsh -ef myproject.list" command.' If myproject.list is long enough (e.g., thousands of lines with reasonable source-code filenames and one line with exploit code), probably most people wouldn't notice that the file isn't legitimate. [1] http://www.openwall.com/lists/oss-security/2012/07/19/6
I'll keep an eye out for patches for this. Based on the discussion on the source forge list, I don't think anything is likely to happen soon. Phillip considers the two recent bugs to be relatively minor (I think that assessment is correct), he doesn't have a lot of time right now and the reporter has irked him. There appear to be fixes to check for other kinds of corruption queued up that may also cause similar issues. I have been keeping an eye out for a 4.3 release, as I am not sure what shape Phillip considers the current trunk to be in. If people think this really warrants a relatively rapid response I can look into seeing if I can find or make fixes?
On RHEL6, the stack smashing protection catches this, but the stack can be corrupted to a point where it causes crashes further down in the glibc abort path, so we can't consider this as fully mitigated. On RHEL5, there's a buffer overflow in the add_exclude function of mksquashfs.c. It's pretty much the same vector, but a different utility and different code (RHEL5 unsquashfs does not seem to support excludes). Luckily, this case seems to be properly mitigated by the stack smashing protection, so this shouldn't be much of a problem.
I looked over the report in a bit more detail. It looks like stopping the problem with a hack should be pretty easy. To see if there is an easy clean fix will require a bit more digging.
(In reply to comment #4) > I looked over the report in a bit more detail. It looks like stopping the > problem with a hack should be pretty easy. To see if there is an easy clean > fix will require a bit more digging. Hi Bruno, I've tried to ping the maintainer several times, so far no reply. It would be awesome if you could look into this and see if you can come up with fixes for CVE-2012-4024 and CVE-2012-4025. If you need help or a review, don't hesitate to contact me. Thanks!
Created squashfs-tools tracking bugs for this issue Affects: fedora-all [bug 847270]
If you read through the thread on the sourceforge list you will see that Phillip doesn't think the bugs are that important (you generally get squashfs images from trusted sources and or are going to be running stuff on them) and the reporter annoyed him, so he isn't inclined to jump in and make fixes for these post haste. When I read through the description I think I understood the problem well enough that I could make a workable fix. I'm sick right now so I probably won't be spending much time on this in the next couple of days. But as I get better I'll take another look at this.
There has been commits (http://squashfs.git.sourceforge.net/git/gitweb.cgi?p=squashfs/squashfs;a=commit;h=3c5901a03a9b6574dbc846a8b900eb95cc6df6f8 http://squashfs.git.sourceforge.net/git/gitweb.cgi?p=squashfs/squashfs;a=commit;h=bda2cc53af0b0e897137800942f42f405d431e1b) that appear to fix this problem. However Phillip has been doing a lot of development recently in trunk so they may not ending up being trivial to back port. We'll see.
None of the hunks apply cleanly, but it looks like they could be manually fixed up without pulling in all of the changes.
I was wrong. The pathname stuff was heavily restructured in October and the commits aren't that helpful for back porting.
I also see that these commits are really fixing a different potential buffer problem with paths. The original add_path issue still needs to be fixed. So for now I'll just keep an eye on things. Those commits were from less than a day ago, so more stuff might be going in very soon.
Phillip has now done a similar commit (http://squashfs.git.sourceforge.net/git/gitweb.cgi?p=squashfs/squashfs;a=commit;h=19c38fba0be1ce949ab44310d7f49887576cc123) for the specific area referred to in CVE-2012-4024.
This patch backported pretty easily. I have a build for rawhide started. If that passes testing, I'll make builds for f16, f17 and f18.
squashfs-tools-4.2-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
squashfs-tools-4.2-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
squashfs-tools-4.2-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Note that squashfs tools 4.3 is due out in a few weeks and will have fixes for a number of potential issues with handling bad data.
Please don't close SRT bugs; this needs to remain open for RHEL6 where it is deferred.
While there hasn't been an official 4.3 release yet, there is a stable branch now. All of the active versions of Fedora have squashfs-tools builds based on that branch. There are many data checking improvements over 4.2. The RHEL maintainer may want to take a look at using that branch for RHEL.