Bug#1070860: musescore3: CVE-2023-44428

2024-05-12 Thread Thorsten Glaser
Moritz Mühlenhoff dixit:

>Am Fri, May 10, 2024 at 06:39:20PM + schrieb Thorsten Glaser:
>> This is a bit like the limited security support for binutils,
>> I suppose. Could/should we document that in the same places?
>
>Sure thing, this sounds similar to what was done for Lilypond,

Ah, okay.

>best to simply ship a similar README.Debian.security within

I was thinking a README.Debian with:

-snip-
Note on possible security issues from untrusted input:

Upstream has never considered it on scope that the software
cannot “crash” on incorrect input, unfortunately. There is
also no security or other support for this version branch
from upstream. Please consider this and don’t expose the
software to untrusted, possibly incorrect, input files to
avoid triggering DoS or possible security problems in its
parsers without suitable confining measures. This is even
more true for import filters than for the native formats’
parsers (and includes the MusicXML import).

Mu͒seScore Studio was designed to operate as an unconnected
desktop program and not as a remotely accessible service,
so please take care.
-snap-

I’ll accept suggestions to improve, of course; I think I’ll
add the magic word “sandboxing” to the last paragraph?

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999



Bug#1070860: musescore3: CVE-2023-44428

2024-05-12 Thread Moritz Mühlenhoff
Am Fri, May 10, 2024 at 06:39:20PM + schrieb Thorsten Glaser:
> This is a bit like the limited security support for binutils,
> I suppose. Could/should we document that in the same places?

Sure thing, this sounds similar to what was done for Lilypond,
best to simply ship a similar README.Debian.security within
the lilypond2 and lilypond3 packages.

Cheers,
Moritz



Bug#1070860: musescore3: CVE-2023-44428

2024-05-10 Thread Thorsten Glaser
Dixi quod…

>Huh. MuseScore (Studio) is a desktop application.

I’ll add a README.Debian note about that fact and that upstream
has never considered crashes on invalid input a bug and that it
hasn’t been designed as a remotely accessible service, but as a
desktop application, and that users should confine suitably.

The Capella import is a vast minority feature and incomplete
anyway, so I douby many users use it directly.

It’ll also document that these versions receive no support
(security or otherwise) from upstream any more (they’ve gone
open-core, proprietary-extension, version 4, which I don’t
intend to package), though there’s a 3.x community effort
whose initiator I know, which I’ve been intending to package
as musescore-snapshot (it’s “tip of the git branch” without
releases to avoid looking official due to the use of the
well-known name) and with whom I’ll cooperate.

This is a bit like the limited security support for binutils,
I suppose. Could/should we document that in the same places?

>I will have to investigate whether they mean indeed this
>or the musescore.com site or mobile äpps or something.

Given the lack of further information, I’ve contacted the ZDI
to get some; otherwise I can run it with valgrind a bit, but
without a reproducer testcase it’s not very likely to find it.

I’ll keep the bugreport informed.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r



Bug#1070860: musescore3: CVE-2023-44428

2024-05-10 Thread Thorsten Glaser
Moritz Mühlenhoff dixit:

>| MuseScore CAP File Parsing Heap-based Buffer Overflow Remote Code
>| Execution Vulnerability. This vulnerability allows remote attackers

Huh. MuseScore (Studio) is a desktop application.
I will have to investigate whether they mean indeed this
or the musescore.com site or mobile äpps or something.

But if there’s a fix for a parsing issue, I’ll backport it
(also to musescore2 if applicable).

Thanks for noticing,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)



Bug#1070860: musescore3: CVE-2023-44428

2024-05-10 Thread Moritz Mühlenhoff
Source: musescore3
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for musescore3.

CVE-2023-44428[0]:
| MuseScore CAP File Parsing Heap-based Buffer Overflow Remote Code
| Execution Vulnerability. This vulnerability allows remote attackers
| to execute arbitrary code on affected installations of MuseScore.
| User interaction is required to exploit this vulnerability in that
| the target must visit a malicious page or open a malicious file.
| The specific flaw exists within the parsing of CAP files. The issue
| results from the lack of proper validation of the length of user-
| supplied data prior to copying it to a heap-based buffer. An
| attacker can leverage this vulnerability to execute code in the
| context of the current process. Was ZDI-CAN-20769.

Unfortunatetly details are sparse, the only reference is
https://www.zerodayinitiative.com/advisories/ZDI-23-1526/


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-44428
https://www.cve.org/CVERecord?id=CVE-2023-44428

Please adjust the affected versions in the BTS as needed.