Bug 935380 - (CVE-2015-4645) VUL-1: CVE-2015-4645,CVE-2015-4646: squashfs: Multiple stack overflows in squashfs-tools
VUL-1: CVE-2015-4645,CVE-2015-4646: squashfs: Multiple stack overflows in squ...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Torsten Duwe
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2015-06-19 08:33 UTC by Marcus Meissner
Modified: 2021-05-31 16:42 UTC (History)
3 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
astieger: needinfo? (duwe)


Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2015-06-19 08:33:46 UTC

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:

Thanks in advance,

Giancarlo Canales Barreto
Comment 1 Marcus Meissner 2015-06-19 08:34:36 UTC
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.
Comment 2 Swamp Workflow Management 2015-06-19 22:00:32 UTC
bugbot adjusting priority
Comment 3 Torsten Duwe 2015-06-29 15:21:14 UTC
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.
Comment 4 Andreas Stieger 2015-07-07 14:24:02 UTC
Patched in Fedora:

Their bugs:

They are using this fix which related to the pull request mentioned, committed in a different repository:

There is a format printing issue related to the type change which was not fixed upstream:

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?