CVE-2021-40826

[plater]

CVE-2021-40826 Clementine Music Player through 1.3.1 is vulnerable to a User Mode Write Access Violation, affecting the MP3 file parsing functionality at clementine+0x3aa207. The vulnerability is triggered when the user opens a crafted MP3 file or loads a remote stream URL that is mishandled by Clementine. Attackers could exploit this issue to cause a crash (DoS) of the clementine.exe process or achieve arbitrary code execution in the context of the current logged-in Windows user.

Nobody in the linux world know if this is a ms windows only issue or if it affects linux clementine too

[DarthGandalf]

Same for CVE-2021-40827

Clementine Music Player through 1.3.1 (when a GLib 2.0.0 DLL is used) is vulnerable to a Read Access Violation on Block Data Move, affecting the MP3 file parsing functionality at memcpy+0x265. The vulnerability is triggered when the user opens a crafted MP3 file or loads a remote stream URL that is mishandled by Clementine. Attackers could exploit this issue to cause a crash (DoS) of the clementine.exe process or achieve arbitrary code execution in the context of the current logged-in Windows user.

Is linux affected?

[hatstand]

This seems like a gstreamer CVE really?

[StayPirate]

Paolo (@VoidSec) can you please provide some extra info here?

[plater]

No the vulnerability has been tested on both openSUSE and Debian and it doesn't work. see: https://bugzilla.suse.com/show_bug.cgi?id=1193881 and https://security-tracker.debian.org/tracker/CVE-2021-40826 Don't know about windows or mac.

[ajakk]

No the vulnerability has been tested on both openSUSE and Debian and it doesn't work. see: https://bugzilla.suse.com/show_bug.cgi?id=1193881 and https://security-tracker.debian.org/tracker/CVE-2021-40826 Don't know about windows or mac.

Can you share reproduction instructions so everyone can confirm?

[DarthGandalf]

From @lumip

I'm currently looking into these and will update the issue you linked once I'm certain what's going on and what the effects are. I'll update you when it's there.

See also #7086 which is the same as this

[lumip]

I have now done some digging on the reported vulnerabilities and both appear to be already fixed.

CVE-2021-40826 was caused by a potential null pointer dereference in MoodbarPipeline::NewPadCallback when it called self->builder_->Init() while self->builder_ was potentially null. This was fixed in commit 55edcf53 a while ago.

CVE-2021-40827 was a bit trickier to track down. I contacted VoidSec to ask for more information and example MP3 files, which they were nice enough to provide :). I have confirmed by wading through the code and some disassembly magic that this is indeed a bug in gstreamer before 1.11.1: Setting the FOOTER flag in while simultaneously providing a tag size of zero in the tag header would cause a uint underflow that in turn resulted in gstreamer trying to read way past the actual buffer size, thus resulting in the read access violation observed in the CVE. (The target buffer was allocated from the heap, so it seems to me that the risk of arbitrary code injection/execution was rather low as there appears no opportunity to redirect execution flow there.) This was fixed in commit d178f762 of the gst-plugins-base repository a couple of years ago. I have also confirmed this with quick runtime checks: Running gst-discoverer-1.0 version 1.10.0 crashes with the malformed input, version 1.12.0 does not (there were no prebuilt Windows binaries for 1.11 available for some reason).

Finally, I have tested the malformed MP3 files with the latest pre-release build of Clementien for Windows (under wine) as well as a local build of master on Kubuntu 20.04 (with gstreamer 1.16.2) and confirmed that crashes no longer occur.

It seems it would be time to release a new version soon since we are currently already sitting on these fixes (and a couple of others) for a while (although I don't know exactly which gstreamer version the Windows build uses, the build workflow handles a file libgsttag-1.0-0.dll but I think/hope that's just a badly chosen name for a more up-to-date version(?)) ...

[ajakk]

I have now done some digging on the reported vulnerabilities and both appear to be already fixed.

CVE-2021-40826 was caused by a potential null pointer dereference in MoodbarPipeline::NewPadCallback when it called self->builder_->Init() while self->builder_ was potentially null. This was fixed in commit 55edcf5 a while ago.

CVE-2021-40827 was a bit trickier to track down. I contacted VoidSec to ask for more information and example MP3 files, which they were nice enough to provide :).

Can you share the mp3 files so everyone else can confirm and debug?

I have confirmed by wading through the code and some disassembly magic that this is indeed a bug in gstreamer before 1.11.1: Setting the FOOTER flag in while simultaneously providing a tag size of zero in the tag header would cause a uint underflow that in turn resulted in gstreamer trying to read way past the actual buffer size, thus resulting in the read access violation observed in the CVE. (The target buffer was allocated from the heap, so it seems to me that the risk of arbitrary code injection/execution was rather low as there appears no opportunity to redirect execution flow there.) This was fixed in commit d178f762 of the gst-plugins-base repository a couple of years ago. I have also confirmed this with quick runtime checks: Running gst-discoverer-1.0 version 1.10.0 crashes with the malformed input, version 1.12.0 does not (there were no prebuilt Windows binaries for 1.11 available for some reason).

Finally, I have tested the malformed MP3 files with the latest pre-release build of Clementien for Windows (under wine) as well as a local build of master on Kubuntu 20.04 (with gstreamer 1.16.2) and confirmed that crashes no longer occur.

It seems it would be time to release a new version soon since we are currently already sitting on these fixes (and a couple of others) for a while (although I don't know exactly which gstreamer version the Windows build uses, the build workflow handles a file libgsttag-1.0-0.dll but I think/hope that's just a badly chosen name for a more up-to-date version(?)) ...

[VoidSec]

Following @lumip's analysis and my preliminary triage, we're pretty confident that the mentioned vulnerabilities cannot be exploited further than causing a Denial of Service (DoS) on the Clementine client. For the above reason, I'm releasing the minimized test cases along with the crash exceptions extracted from my Windows OS.

Looking at the samples, I'll suggest looking at the struct_ID3v2_FRAME_tf -> size being set to a huge value.

     ID3v2_TAG
        ID3v2_HEADER
            head
            v_major
            v_minor
            flags
            size
        ID3v2_FRAME
            id
            size <-- HERE
            flags

• crashes.zip

Please, for future references, keep the wiki page related to building Clementine from source code updated. I've tried re-building it for Windows (with symbols support) from the source code for almost 2 days before giving up. I would have been more efficient in fuzzing it. Without the debug symbols the triage was so complicated that, due to time constraints, I was not able to perfectly pinpoint the root cause of the crash.

I'm not familiar with the project but, as the fixes were referencing quite old commits (~4-5 years ago), is there any good reason why you're not shipping a new release? Because unless you'll push out a new release, the end-users are still impacted by those vulnerabilities plus all the bugs that were fixed in the last 5 years...

Regarding issue #7086, is there any way I could help you set up a security policy?