An issue was discovered in Oniguruma 6.x before 6.9.4_rc2. In the function gb18030_mbc_enc_len in file gb18030.c, a UChar pointer is dereferenced without checking if it passed the end of the matched string. This leads to a heap-based buffer over-read. Reference: https://github.com/kkos/oniguruma/issues/163 https://github.com/kkos/oniguruma/releases/tag/v6.9.4_rc2 https://github.com/ManhNDd/CVE-2019-19203 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/NO267PLHGYZSWX3XTRPKYBKD4J3YOU5V/ https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V3MBNW6Z4DOXSCNWGBLQ7OA3OGUJ44WL/
Created oniguruma tracking bugs for this issue: Affects: epel-7 [bug 1802063] Affects: fedora-30 [bug 1802064]
Upstream fix: https://github.com/kkos/oniguruma/commit/aa0188eaedc056dca8374ac03d0177429b495515
When handling regular expressions with GB18030 character encoding, function match_at() in regexec.c calls gb18030_mbc_to_code() through macro ONIGENC_IS_MBC_WORD: https://github.com/kkos/oniguruma/blob/v6.9.3/src/regexec.c#L3183. Function gb18030_mbc_to_code() takes a UChar pointer to the regexp matching string and reads an OnigCodePoint from it. However, the pointer is previously incremented in CCLASS switch case: https://github.com/kkos/oniguruma/blob/v6.9.3/src/regexec.c#L3003. If the matching string is a malformed 2-byte string (such as "\xe1\xe1" in PoC), this will lead to an out-of-bounds read of 1 byte as the pointer argument points into the middle of the matching string.
The out-of-bounds read does not occur in Oniguruma upstream versions prior to v6.9.2; the flaw was apparently introduced in version v6.9.2 with commit https://github.com/kkos/oniguruma/commit/3661ae526bc1cfe1b93ec31fc03c0fe72e1fe6c1. This commit modified the way the matching string pointer is incremented in CCLASS switch case (see comment #5). Specifically, the `enclen` macro was replaced with ++ operator to increment the pointer. `enclen` was able to detect the size of the string and increment the pointer properly, preventing ONIGENC_IS_MBC_WORD to be reached due to size checks in DATA_ENSURE macro: https://github.com/kkos/oniguruma/blob/v6.9.3/src/regexec.c#L3182.
Note that the versions of Ruby as shipped with Red Hat Enterprise Linux and Red Hat Software Collections 3 do not use Oniguruma but rather Onigmo, a regular expressions library forked from Oniguruma focusing on new expressions supported in Perl 5.10+.
The following containers are packaged with OpenShift 4.x and contain a vulnerable version of oniguruma (5.9.x): - openshift4/ose-metering-hadoop - openshift4/ose-metering-hive - openshift4/ose-metering-presto However, these containers include oniguruma but do not use it. This includes faq and jq which may use oniguruma, and are included within the containers but are unused. Red Hat Core OS also includes oniguruma (6.8.3 which is also vulnerable) as a dependency of jq.
Created oniguruma tracking bugs for this issue: Affects: openstack-rdo [bug 1814168]
(In reply to Mauro Matteo Cascella from comment #7) > Note that the versions of Ruby as shipped with Red Hat Enterprise Linux and > Red Hat Software Collections 3 do not use Oniguruma but rather Onigmo, a > regular expressions library forked from Oniguruma focusing on new > expressions supported in Perl 5.10+. So is Ruby vulnerable or not? I don't think it is, since it does more checks prior feeding the data into Oniguruma/Onigmo: ~~~ $ ruby -e 's = "[\\W]\\w\xa1".force_encoding Encoding::GB18030 > Regexp.new s' -e:2:in `initialize': invalid multibyte character: /[\W]\w\xA1/ (RegexpError) from -e:2:in `new' from -e:2:in `<main>' $ rpm -q ruby ruby-2.0.0.648-36.el7.x86_64 ~~~
Hello Vit, although it doesn't seem possible to trigger the flaw (as you pointed out), we consider all versions of Ruby to be affected because they include the same vulnerable code as Oniguruma in enc/gb18030.c and regenc.c; the patch has not been backported and we cannot rule out it might still be possible to trigger the flaw in other ways/future versions. I do agree this is a low-severity issue in Ruby for the reason above, so if you think it's not worth spending more time on it please feel free to WONTFIX the related tracking bugs.
Statement: This flaw did not affect the versions of Oniguruma (embedded in php) as shipped with Red Hat Enterprise Linux 5, as they did not include support for GB18030 character encoding, which was introduced in a later version of the library. The versions of Ruby as shipped with Red Hat Enterprise Linux and Red Hat Software Collections 3 do not use Oniguruma but rather Onigmo, a regular expressions library forked from Oniguruma focusing on new expressions supported in Perl 5.10+. Those versions are affected by this flaw because both Onigmo and Oniguruma share the same vulnerable code. However, Ruby does perform additional checks which prevent the vulnerable code path to be easily reached, hence lowering the severity of the flaw.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:3662 https://access.redhat.com/errata/RHSA-2020:3662
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2019-19203
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS Via RHSA-2020:5275 https://access.redhat.com/errata/RHSA-2020:5275
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2024:0409 https://access.redhat.com/errata/RHSA-2024:0409
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:0572 https://access.redhat.com/errata/RHSA-2024:0572
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:0889 https://access.redhat.com/errata/RHSA-2024:0889