Le 05/08/2022 à 11:43, Neil Williams a écrit :
On Mon, 1 Aug 2022 18:25:04 +0200 Sylvestre Ledru <sylves...@mozilla.com> wrote:
Hello,
Le 05/07/2022 à 11:19, Neil Williams a écrit :
Source: scilab
Version: 6.1.1+dfsg2-3
Severity: important
Tags: security
X-Debbugs-Cc: codeh...@debian.org, Debian Security Team
<t...@security.debian.org>
Hi,
The following vulnerability was published for scilab.
CVE-2022-30045[0]:
| An issue was discovered in libezxml.a in ezXML 0.8.6. The function
| ezxml_decode() performs incorrect memory handling while parsing
| crafted XML files, leading to a heap out-of-bounds read.
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-2022-30045
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30045
Please adjust the affected versions in the BTS as needed.
While Scilab indeed ships ezxml.c, I am not sure how this can be exploited.
The code is probably only used to load scicos/xcos schema.
https://github.com/scilab/scilab/blob/b0937f19e4b8ddf416ca9a9a433bcbbd3f4ef2c0/scilab/modules/scicos/src/c/ezxml.c
Am I right in thinking that XCOS Schema can be provided by third-parties/users?
(
https://github.com/scilab/scilab/blob/master/scilab/contrib/xcos_toolbox_skeleton/help/en_US/available_blocks.xml
)
What would the effect be of a crash during parsing a corrupt XCOS Schema loaded
via a help file, for example?
I think the XML parsing is done elsewhere
But anyway, I proposed a fix upstream:
https://gitlab.com/scilab/scilab/-/merge_requests/1
Cheers
S
