I would guess that they mean 0.91, but this is to be confirmed

On 5/19/22 15:36, John Cliff wrote:

The individual CVE pages say Inkscape 0.19, do they mean 0.91?

On Thu, May 19, 2022 at 12:24 PM Thomas Leroy tleroy@suse.de wrote:

Hi there,

As you may know, 3 CVEs [0] [1] [2] have been assigned to Inkscape, but there
are a very few information available.
The 3 CVE pages redirect to the same CISA page [3], mentioning Inkscape
version
1.0 or later as fixed. Could you please confirm this information?
Moreover, in the case of backporting patches is preferred instead of
upgrading,
could you please point me to the fixing commits? That would be very awesome.:)

Best regards,

Thomas

[0]https://nvd.nist.gov/vuln/detail/CVE-2021-42700
[1]https://nvd.nist.gov/vuln/detail/CVE-2021-42702
[2]https://nvd.nist.gov/vuln/detail/CVE-2021-42704
[3]https://www.cisa.gov/uscert/ics/advisories/icsa-22-132-03

-- 
Thomas Leroy
Security engineer
SUSE Software Solutions
_______________________________________________
Inkscape Devel mailing list -- inkscape-devel@lists.inkscape.org
To unsubscribe send an email to inkscape-devel-leave@lists.inkscape.org

Hi Marc,

Thank you very much for these indications. The 3 CVEs mention oob read, write and use of uninitialized pointer, so I'm going to take a look to the last libuemf changes, to identify what could look like security fixes. If only the oob read is proven, we will need to dispute some of these CVEs.

Now about your concerns about the CVE(s) severity, if the oob read and write really exist, it should be fairly enough to at least crash the executing process, but also probably get code execution with a bypass of all the mitigations. That's why the CISA report mentions a 7.8 CVSS, which is quite high. But in both cases, a user interaction is needed to load a malicious file (a malicious EMF file I guess in this case). Since the bugs are not in a privileged process (I guess?), or remotely triggerable, the severity could actually be worse. It doesn't make these bugs very interesting. But an attacker with a working exploit could still convince a victim to load the exploit, and get code execution on the victim's machine. Now, if only the oob read is verified, the attack scenario is still the same, but the impact would only be a local deny of service by crashing the process, which is indeed not very scaring. An attacker could try to search for sensitive information in the process memory (if such exists), but getting back the extracted information in a local desktop app, without other primitives, is another story. :)

Best,

Thomas

On 5/20/22 00:13, Marc Jeanmougin wrote:

Hi Thomas,

we were informed that a third-party vendor shipping a custom installer for a quite old (0.91 : 7 years ago) Inkscape version, found a oob read in a parser in libuemf, the library we use to read emf files. The report itself mentioning that 1.0+ was unaffected, we trusted it with that[1][2], and having no intention of releasing new point releases for versions older than 1.1.x , afaict no action was required from us. If you're looking to backport a "fix" for a very old Inkscape version, the easiest way would probably be to copy the files from a recent libuemf upstream source[3], into the src/libuemf/ (now src/3rdparty/libuemf/) folder which is a rather standalone part of the codebase.

Bests,