An issue was discovered in Oniguruma 6.x before 6.9.4_rc2. In the function fetch_interval_quantifier (formerly known as fetch_range_quantifier) in regparse.c, PFETCH is called without checking PEND. This leads to a heap-based buffer over-read. Reference: https://github.com/kkos/oniguruma/issues/162 https://github.com/kkos/oniguruma/releases/tag/v6.9.4_rc2 https://github.com/ManhNDd/CVE-2019-19204 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 1802072] Affects: fedora-30 [bug 1802073]
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 likewise, are unused.
Upstream fix: https://github.com/kkos/oniguruma/commit/6eb4aca6a7f2f60f473580576d86686ed6a6ebec
While handling regular expressions quantifiers, function fetch_range_quantifier() in regparse.c repeatedly calls PFETCH() to fetch the current OnigCodePoint and increment the associated pointer to a heap-allocated buffer storing the regular expression. In some cases it may end up calling PFETCH() two consecutive times on the last element, causing a heap out-of-bounds read of (at most) 4 bytes (OnigCodePoint is a typedef unsigned int).
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+. It turns out this flaw affects Onigmo as well, as both Onigmo and Oniguruma share the same vulnerable code.
Update to Comment 2: 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 1814169]
I don't think that Ruby is vulnerable. Ruby is doing its own pre-processing of the string, which is already sanitized before it is fed into Oniguruma. E.g. this example fails on Ruby side: ~~~ $ ruby -e 'Regexp.new "_\\{21\\"' -e:1:in `initialize': too short escape sequence: /_\{21\/ (RegexpError) from -e:1:in `new' from -e:1:in `<main>' $ rpm -q ruby ruby-2.0.0.648-36.el7.x86_64 ~~~ Also, Ruby 2.4.0+ is not affected: https://github.com/ruby/ruby/commit/2873edeafb6f6df1fc99bb9b1167591b99dd378c because the same issue in Onigmo was fixed way earlier: https://github.com/k-takata/Onigmo/commit/29e7e6aedebafd5efbbd90655c8e0d495035d7b4
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-19204
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