Bugzilla – Bug 935380
VUL-1: CVE-2015-4645,CVE-2015-4646: squashfs: Multiple stack overflows in squashfs-tools
Last modified: 2021-05-31 16:42:20 UTC
CVE-2015-4646 http://seclists.org/oss-sec/2015/q2/746 From: Giancarlo Canales <gcanalesb () me com> Date: Wed, 17 Jun 2015 19:26:49 -0400 I recently discovered several highly similar stack overflow weakness in squashfs-tools and sasquatch. This issue has already been made public to both projects, with recommendations on how to fix them, but a fix has not been released by the project maintainers. Sasquatch is an experimental fork of squashfs-tools. Squashfs-tools is present in the repositories of Debian, CentOS, and other Linux distributions. The vulnerability can be exploited by using the unsquashfs command to unpack a malicious squashfs image that causes a stack overflow in an unchecked variable length array. Thereafter, a function that copies data from the squashfs image to the overflown array is executed. I’m requesting a CVE number for this vulnerability, per project. Title: Stack overflows in squash-fs Products: squash-fs Affects: All versions Type: Stack overflow First CVE ID Request: Yes Title: Stack overflows in sasquatch Products: sasquatch Affects: All versions Type: Stack overflow First CVE ID Request: Yes Fore information about the stack overflow, please visit: https://github.com/devttys0/sasquatch/pull/5 Thanks in advance, Giancarlo Canales Barreto
From Mitre: As far as we can tell, there are two independent types of problems: We would guess that the most likely case is that only 3 and 6 are applicable, i.e., the code problems are found only in unsquash-1.c/unsquash-2.c/unsquash-3.c/unsquash-4.c and all of these files exist in both squashfs-tools and sasquatch. Is this correct? Yes, that is correct. - "int bytes" is incorrect because the return value of SQUASHFS_FRAGMENT_BYTES can be larger than the maximum value of a signed int Use CVE-2015-4645. - pull/5 says "If we fix this by making the variable size_t, we run into an unrelated problem in which the stack VLA allocation of fragment_table_index[] can easily exceed RLIMIT_STACK" but actually RLIMIT_STACK can be exceeded regardless of the data type of the bytes variable Use CVE-2015-4646.
bugbot adjusting priority
The issue seems to be real: if you create or fake a squashfs with > 256M fragments, with sizeof(squashfs_fragment_entry) == 16, it will overflow an int32 for the required size. The squashfs package .h has int, short and long long for the superblock data types (YUCK!), but the kernel stipulates int32 for #fragments.
Patched in Fedora: http://007software.net/fedora-21-security-update-squashfs-tools-4-3-11-fc21/ https://admin.fedoraproject.org/updates/FEDORA-2015-10760/squashfs-tools-4.3-11.fc21 Their bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1234886 https://bugzilla.redhat.com/show_bug.cgi?id=1234888 They are using this fix which related to the pull request mentioned, committed in a different repository: https://github.com/gcanalesb/sasquatch/commit/6777e08cc38bc780d27c69c1d8c272867b74524f There is a format printing issue related to the type change which was not fixed upstream: http://pkgs.fedoraproject.org/cgit/squashfs-tools.git/tree/local-cve-fix.patch However the researcher explicitly marked this as an example of the vulnerability, not a complete fix by any means. From https://github.com/devttys0/sasquatch/pull/5 : > This pull request is an example implementation of the recommended fix for unsquash-4, > but I don't have enough test vectors to verify it doesn't break anything. All code that > uses VLA should probably be converted to use the heap instead. Torsten, based on the partial fix for unsquash-4, can you develop a patch fixing all occurrences in squashfs-tools, and propose this to upstream? Maybe also include local-cve-fix.patch as this seems obvious?