Clicking on PFE-Jump-link nav link goes to the wrong part of the page #1784
Description
Description of the issue
Implemented PFE Jump Link on DXP Security Platform, in order to get a good anchor link experience we created our own "autobuild" JS that runs before the component mounts. We're finding when the component does it's thing, and you click on a nav item, it scrolls to the wrong place.
This bit produces the correct value for where to scroll to:
https://github.com/patternfly/patternfly-elements/pull/1652/files#diff-4b2e0e8217620d6f114d6bd00d1daa3990676091a5fd34aa73e6c3f5fdfb1a08R914
This bit messes it up:
https://github.com/patternfly/patternfly-elements/pull/1652/files#diff-4b2e0e8217620d6f114d6bd00d1daa3990676091a5fd34aa73e6c3f5fdfb1a08R949-R951
Not sure what that code is supposed to be doing, I think this will effect jump links without an offset, I believe the examples on the patternfly site do have an offset.
Impacted component(s)
- pfe-jump-links
Steps to reproduce
- This env may go away, if it does you can ask @wesruv or Melissa Bent where to get a new link
- Go to https://dxp-security-141.ext.us-east.aws.preprod.paas.redhat.com/adminlogin/admin
- Go to https://dxp-security-141.ext.us-east.aws.preprod.paas.redhat.com//node/add/vulnerability
- Click "Source" in WYSIWYG
- Paste the below HTML
- Publish page
- Click on nav link
<h2>Executive summary</h2><p>Red Hat is aware of a flaw found in runc where an attacker who can deploy a container could potentially escape from the container to the host system. This issue has been assigned <a href="https://access.redhat.com/security/cve/CVE-2021-30465"><u>CVE-2021-30465</u></a> and has been rated with a severity impact of <a href="https://access.redhat.com/security/updates/classification"><u>Important</u></a>. If <a href="https://docs.google.com/document/d/1CwzF0iaoFTmu9yljlBvuVK7MOJKSspjPrXP7fssCScE/edit#heading=h.7xsvcs2ufxph"><u>SELinux</u></a> is running in enforcing mode, the impact is reduced.</p><p>The following Red Hat product versions are directly affected:</p><ul> <li>Red Hat Enterprise Linux 8</li> <li>Red Hat OpenShift Container Platform 4.x</li> <li>Red Hat Enterprise Linux 7</li> <li>Red Hat OpenShift Container Platform 3.x</li></ul><p>Further, any Red Hat product supported on the Red Hat Enterprise Linux platform is also potentially impacted. This includes products that pull packages from the RHEL channel. Please ensure that the underlying Red Hat Enterprise Linux runc or docker package is current in these product environments.</p><p>To determine if your system is currently vulnerable to this flaw, see the Diagnose section below. Additionally, an Ansible playbook for automatic remediation is provided below.</p><h2>Technical summary</h2><p>A vulnerability discovered in runc allows a break out from the container and gains access to the host filesystem.</p><p>This vulnerability affects runc and all its dependent container tools packages available on Red Hat Enterprise Linux (RHEL) 8. OpenShift Container Platform (OCP) 4.x is also affected as it also uses runc via cri-o.</p><p>This vulnerability affects both the docker and runc packages available on Red Hat Enterprise Linux 7, which are delivered through the Extras channel. OpenShift Container Platform (OCP) 3.x depends on these packages from Red Hat Enterprise Linux 7 Extras and is also affected.</p><h2>Mitigation</h2><p> </p><p>The impact of the vulnerability is reduced if SELinux is in enforcing mode using the container-selinux policy. The container-selinux policy is installed and enabled by default on RHEL 7 and 8, as well as OpenShift Container Platform 3.x and 4.x.</p><p>Customers running affected versions of RHEL are strongly recommended to apply RPM updates from the RHEL 8 channel and RHEL 7 Extras channel as soon as errata becomes available. </p><p>Customers running affected versions of OpenShift Container Platform are strongly recommended to upgrade as soon as errata becomes available.</p><p>Customers of OpenShift Dedicated and Azure Red Hat OpenShift have SELinux enabled in enforcing mode in every host across all clusters. Therefore, It is expected that OSD/ARO both have a reduced impact from this issue, with security patches made available during upcoming maintenance windows.</p><h2>Technical details</h2><p>The runc package is vulnerable to a symlink exchange attack whereby an attacker can request a seemingly innocuous container configuration that results in the host filesystem being bind-mounted into the container.</p><p>The runc package can be used standalone to run containers, however it is usually used by other packages to run containers. On RHEL 8, the container-tools module package, podman, uses runc and is therefore vulnerable via its dependency on runc. OCP 4 is vulnerable via the cri-o package, which uses runc. On RHEL-7, the docker package embeds runc and is vulnerable to this issue. OCP 3 uses the docker package in its default configuration and is also affected. OCP 3 can be configured to use cri-o instead of docker, and in that case, is affected as well.</p><p>In circumstances where a container is being started, and runc is mounting inside a volume shared with another container (which is conducting a symlink-exchange attack), runc can be tricked into mounting outside of the container root filesystem by swapping the target of a mount with a symlink due to a time-of-check-to-time-of-use (TOCTTOU) flaw.</p><p>However, this alone is not useful because this happens inside a mount namespace with "MS_SLAVE" propagation applied to "/" (meaning that the mount doesn't appear on the host -- it's only a "host-side mount" inside the container's namespace). To exploit this, you must have additional mount entries in the configuration that use some subpath of the mounted-over host path as a source for a subsequent mount.</p><h3>Product impact</h3><h4>OpenShift Container Platform</h4><p>In the case of OpenShift Container Platform, this issue is exploitable by creating a symlink in a volume to the top-level (well-known) directory where volumes are</p><p>sourced from (for instance, "/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir"),</p><p>and then using that symlink as the target of a mount. </p><p> </p><p>The source of the mount is an attacker-controlled directory, and thus the source directory from which subsequent mounts will occur is an attacker-controlled</p><p>directory. The attacker can first place a symlink to "/" in their malicious source directory with the name of a volume, and a subsequent mount in the container will bind-mount "/" into the container.</p><p> </p><p>The impact of the vulnerability is reduced if SELinux is in enforcing mode using the container-selinux policy. The container-selinux policy is installed and enabled by default on OpenShift Container Platform 3.x and 4.x.</p><h3>Service impact</h3><h4>OpenShift Dedicated and Azure Red Hat OpenShift</h4><p>In OpenShift Dedicated (OSD) and Azure Red Hat OpenShift (ARO) each customer has one or more dedicated clusters and does not share these clusters. As a result, exposure is limited to only that customer.</p><p>OpenShift Dedicated and Azure Red Hat OpenShift customers have SELinux enabled in enforcing mode in every host across all clusters, which reduces the impact (more details on the FAQ below).</p><p>This vulnerability can be exploited only if an attacker is able to deploy a container. Deploying containers in OSD/ARO is only possible for authenticated and authorized users. Red Hat recommends that only trusted containers are deployed (ex. verify that they come from a trusted source, Health Index is ok [6])</p><h4>Red Hat Developer Sandbox</h4><p>The vulnerable package is present in the Red Hat Developer Sandbox as a transitive dependency of another package. It is neither used nor needed, and the service is not affected. In any case, during an upcoming maintenance window, the package is removed.</p><h4>Red Hat OpenShift API Management</h4><p>The vulnerable package is present in the Red Hat OpenShift API Management code base. Only administrators of the managed service can deploy containers, which are verified and trusted before deployment. The service has not been affected and the risk is low. In any case, during an upcoming maintenance window, the vulnerable package is upgraded. </p><p> </p><h2>Updates for affected products</h2><p>Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as erratas are available. Customers are urged to apply the available updates immediately or enable the mitigations as they feel appropriate. </p><div><table> <colgroup> <col /> <col /> <col /> <col /> </colgroup> <tbody> <tr> <td> <p>Product</p> </td> <td> <p>Variant</p> </td> <td> <p>Component(s)</p> </td> <td> <p>Advisory/Update</p> </td> </tr> <tr> <td> <p>OpenShift Enterprise 3</p> </td> <td> <p>3.11</p> </td> <td> <p>runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2150"><u>RHSA-2021:2150</u></a></p> </td> </tr> <tr> <td> <p><s>OpenShift Enterprise 3</s></p> </td> <td> <p><s>3.11</s></p> </td> <td> <p><s>docker</s></p> </td> <td> <p><s>[1]</s></p> </td> </tr> <tr> <td> <p>OpenShift 4</p> </td> <td> <p>4.7</p> </td> <td> <p>runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:1562"><u>RHSA-2021:1562</u></a></p> </td> </tr> <tr> <td> <p>OpenShift 4</p> </td> <td> <p>4.6</p> </td> <td> <p>runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:1566"><u>RHSA-2021:1566</u></a></p> </td> </tr> <tr> <td> <p>OpenShift 4</p> </td> <td> <p>4.5</p> </td> <td> <p>runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2057"><u>RHSA-2021:2057</u></a></p> </td> </tr> <tr> <td> <p>Red Hat Enterprise Linux 7</p> </td> <td> </td> <td> <p>runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2145"><u>RHSA-2021:2145</u></a></p> </td> </tr> <tr> <td> <p>Red Hat Enterprise Linux 7</p> </td> <td> </td> <td> <p>docker</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2144"><u>RHSA-2021:2144</u></a></p> </td> </tr> <tr> <td> <p><s>Red Hat Enterprise Linux 8</s></p> </td> <td> <p><s>z-stream</s></p> </td> <td> <p><s>container-tools:1.0/runc</s></p> </td> <td> <p><s>[1]</s></p> </td> </tr> <tr> <td> <p>Red Hat Enterprise Linux 8</p> </td> <td> <p>z-stream</p> </td> <td> <p>container-tools:rhel8/runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2371"><u>RHSA-2021:2371</u></a> </p> </td> </tr> <tr> <td> <p>Red Hat Enterprise Linux 8</p> </td> <td> <p>z-stream</p> </td> <td> <p>container-tools:2.0/runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2291"><u>RHSA-2021:2291</u></a><br /> <a href="https://access.redhat.com/errata/RHSA-2021:2292"><u>RHSA-2021:2292</u></a></p> </td> </tr> <tr> <td> <p>Red Hat Enterprise Linux 8</p> </td> <td> <p>z-stream</p> </td> <td> <p>container-tools:3.0/runc</p> </td> <td> <p><a href="https://access.redhat.com/errata/RHSA-2021:2370"><u>RHSA-2021:2370</u></a></p> </td> </tr> </tbody></table></div><p> </p><p>[1] Advisory/Update link will be added once updates are live.</p><p>[2] <a href="https://access.redhat.com/solutions/22763">What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?</a></p><p>[3] <a href="https://access.redhat.com/solutions/2975771">What is Advanced mission critical Update Support (AUS)?</a></p><p>[4] <a href="https://access.redhat.com/solutions/3082481">What is the Red Hat Enterprise Linux SAP Solutions subscription?</a></p><p>[5] An active <a href="https://access.redhat.com/support/policy/updates/errata#Extended_Life_Cycle_Support">Extended Life-cycle Support (ELS)</a> subscription is required for access to this patch. Please <a href="https://www.redhat.com/en/contact">contact</a> Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.</p><p>[6] Product containers which use the Red Hat Enterprise Linux base image. Base images will be updated to include fixes for this flaw, please ensure containers are current. The Container Health Index, part of the<a href="https://access.redhat.com/containers/"> Red Hat Container Catalog</a>, can be used to verify the security status of Red Hat containers.</p><p>[7] Products which pull packages from the RHEL channel. Please ensure that the underlying Red Hat Enterprise Linux runc or docker package is current in these product environments</p><p> </p><h2>Diagnose</h2><p> </p><p>A vulnerability detection script has been developed to determine if your system is currently vulnerable to this flaw. To verify the authenticity of the script, you can download the detached GPG signature [insert link] as well. Instructions on <a href="https://access.redhat.com/articles/5433831">how to use GPG signature for verification </a>are available on the Customer Portal. </p><p> </p><p>Determine if your system is vulnerable</p><p>Current version: 1.0</p><p><a href="https://access.redhat.com/sites/default/files/cve-2018-12130--2019-06-10-1646.sh">DOWNLOAD DETECTION SCRIPT</a></p><p> </p><h3>Ansible Playbook</h3><p>Additionally, an Ansible playbook is provided below. This playbook will update affected x packages. To use the playbook, specify the hosts you'd like to update with the HOSTS extra var:</p><p>[insert yml]</p><p>To verify the legitimacy of the playbook, you can download the detached GPG signature [insert link] as well. Instructions on <a href="https://access.redhat.com/articles/5433831">how to use GPG signature for verification</a> are available on the Customer Portal. </p><h2>FAQ</h2><p>Q: Does SELinux mitigate this vulnerability?</p><p>A: While it’s still possible to exploit the vulnerability when SELinux is in enforcing mode the impact of the vulnerability is reduced. An attacker would have the host file system mounted in a container process with an SELinux label. SELlinux prevents you from getting access to files or sockets <a href="https://opensource.com/business/13/11/selinux-policy-guide"><u>which aren't allowed by your label</u></a>. It may still be possible to leverage the vulnerability to have some impact on confidentiality, integrity or availability of the host operating system.</p><p>Q: What is the likelihood of this vulnerability being exploited?</p><p>A: If you allow untrusted users to run containers in your environment or allow trusted users to deploy untrusted containers in your environment, then you are more likely to be impacted by this issue.</p><h2>Acknowledgements</h2><p>Red Hat thanks the upstream Open Containers Security Team for reporting this issue. Upstream acknowledges Etienne Champetier as the researcher who discovered this flaw.</p><h2>References</h2><p><a href="https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r"><u>https://github.com/opencontainers/runc/security/advisories/GHSA-c3xm-pvg7-gh7r</u></a></p><p><a href="https://access.redhat.com/articles/5433831">How to use GPG to verify signed content from Product Security </a></p><p> </p>