RDoc used to call Kernel#open to open a local file. If a Ruby project has a file whose name starts with | and ends with tags, the command following the pipe character is executed. A malicious Ruby project could exploit it to run an arbitrary command execution against a user who attempts to run rdoc command. References: https://www.ruby-lang.org/en/news/2021/05/02/os-command-injection-in-rdoc/
Upstream commit: https://github.com/ruby/rdoc/commit/a7f5d6ab88632b3b482fe10611382ff73d14eed7
This issue was fixed in RDoc versions distributed with Ruby in Ruby versions 3.0.2, 2.7.4, and 2.6.8: https://www.ruby-lang.org/en/news/2021/07/07/ruby-3-0-2-released/ https://www.ruby-lang.org/en/news/2021/07/07/ruby-2-7-4-released/ https://www.ruby-lang.org/en/news/2021/07/07/ruby-2-6-8-released/
This issue was introduced in RDoc version 3.11 via the following commit, which added functionality to skip processing of the "tags" files: https://github.com/ruby/rdoc/commit/4a8b7bed7cd5647db92c620bc6f33e4c309d2212
Created ruby tracking bugs for this issue: Affects: fedora-all [bug 1980570] Created ruby:2.5/ruby tracking bugs for this issue: Affects: fedora-34 [bug 1980571] Created ruby:2.6/ruby tracking bugs for this issue: Affects: fedora-all [bug 1980567] Created ruby:2.7/ruby tracking bugs for this issue: Affects: fedora-all [bug 1980568] Created ruby:master/ruby tracking bugs for this issue: Affects: fedora-all [bug 1980569]
One potential concern related to this issue can be the fact that by default the gem command uses rdoc to generate documentation for all gems it installs. However, any gems installed has to be trusted, as code included in those gems gets executed - as part of an application requiring particular gems or even during gem installation. Therefore, this flaw does not seem to open any new exposure in this use case. Users who prefer to not have rdoc invoked during gem installation can disable its use using the --no-document command line option for 'gem install' or 'gem update' commands. Additionally, the --no-document option can be made the default via gemrc configuration file - either user-specific ~/.gemrc or system /etc/gemrc. Adding the following line to a gemrc file makes --no-document default for all gem sub-commands (including 'install' and 'update'): gem: --no-document Note that the --no-document option was added in gem / rubygems version 2.0.0. For earlier versions options --no-rdoc and --no-ri need to be used instead. Those options can be made default via a gemrc file in a similar way as noted above. These concerns do not apply to gem installation using Bundler, as it does not invoke rdoc during package installation.
The only active version of Red Hat CloudForms is 5.11 atm, which is also in maintenance support phase already and does not ship ruby or rubygem-rdoc directly.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:3020 https://access.redhat.com/errata/RHSA-2021:3020
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-2021-31799
This issue is currently scored by NVD with the following CVSS score: 9.8/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H There are few differences in how Red Hat scores this issue, notably: AV:L - RDoc processes source code that is available locally, this vulnerability is not bound to the network stack. Per the CVSS scoring guide, this issue is to be considered as Local. Remote attacker can only exploit this issue by first using some other ways to make their malicious source code available locally to where RDoc will be run. AC:H - An attacker needs to determine a target-specific ways to get their malicious source code on the target system and have it processed by RDoc. This may involve additional interaction with a victim who will manually run RDoc, implying UI:R. One generic way to get malicious source code on a target system is via installation of a gem package with the code form a gem packages repository (such as rubygems.org) using the gem command, which invokes RDoc on all installed packages by default. This use case is already discussed in the comment 9 above, noting that any package installed this way should be considered trusted. Code included in those packages is typically executed as part of some Ruby application. Gem packages can also execute arbitrary code during installation via mechanisms to build native extensions. Therefore, there does not seem to be any trust boundary crossed in this use case. This issue seems to have the greatest risk for Ruby code hosting services. For those, attacker may need to be authenticated to upload their malicious source code. Note that these would only be affected if RDoc is invoked from the directory containing the source code, uses when RDoc is invoked form a different directory with the source code directory specified as RDoc command line argument (e.g. 'rdoc /path/to/malicious/code', possibly along with the use of -o option to specify output directory) are not affected.
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.7 EUS Via RHSA-2021:3559 https://access.redhat.com/errata/RHSA-2021:3559
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.7 EUS Via RHSA-2021:3982 https://access.redhat.com/errata/RHSA-2021:3982
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:0543 https://access.redhat.com/errata/RHSA-2022:0543
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Extended Update Support Via RHSA-2022:0544 https://access.redhat.com/errata/RHSA-2022:0544
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Update Services for SAP Solutions Via RHSA-2022:0581 https://access.redhat.com/errata/RHSA-2022:0581
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Extended Update Support Via RHSA-2022:0582 https://access.redhat.com/errata/RHSA-2022:0582
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:0672 https://access.redhat.com/errata/RHSA-2022:0672
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Via RHSA-2022:0708 https://access.redhat.com/errata/RHSA-2022:0708