[Bugs] [Bug 13327] New: [CVE 21] tar 1.34 CVEs found

[bugzilla]

https://bugzilla.rosalinux.ru/show_bug.cgi?id=13327

          Platform: 2021.1
            Bug ID: 13327
           Summary: [CVE 21] tar 1.34  CVEs found
    Classification: ROSA-based products
           Product: ROSA Fresh
           Version: All
          Hardware: All
               URL: CVE-2021-32803, CVE-2021-32804, CVE-2021-37701,
                OS: Linux
            Status: CONFIRMED
          Severity: normal
          Priority: Normal
         Component: System (kernel, glibc, systemd, bash, PAM...)
          Assignee: bugs на lists.rosalinux.ru
          Reporter: y.tumanov на rosalinux.ru
        QA Contact: bugs на lists.rosalinux.ru
                CC: s.matveev на rosalinux.ru, y.tumanov на rosalinux.ru
  Target Milestone: ---
             Flags: secteam_verified?

Please patch CVEs for package tar version 1.34

INFO (CVEs are): tar 1.34
 cves found
CVE-2021-32803
Desc: The npm package "tar" (aka node-tar) before versions 6.1.2, 5.0.7,
4.4.15, and 3.2.3 has an arbitrary File Creation/Overwrite vulnerability via
insufficient symlink protection. `node-tar` aims to guarantee that any file
whose location would be modified by a symbolic link is not extracted. This is,
in part, achieved by ensuring that extracted directories are not symlinks.
Additionally, in order to prevent unnecessary `stat` calls to determine whether
a given path is a directory, paths are cached when directories are created.
This logic was insufficient when extracting tar files that contained both a
directory and a symlink with the same name as the directory. This order of
operations resulted in the directory being created and added to the `node-tar`
directory cache. When a directory is present in the directory cache, subsequent
calls to mkdir for that directory are skipped. However, this is also where
`node-tar` checks for symlinks occur. By first creating a directory, and then
replacing that directory with a symlink, it was thus possible to bypass
`node-tar` symlink checks on directories, essentially allowing an untrusted tar
file to symlink into an arbitrary location and subsequently extracting
arbitrary files into that location, thus allowing arbitrary file creation and
overwrite. This issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.
Link: https://nvd.nist.gov/vuln/detail/CVE-2021-32803
Severity: HIGH
CVE-2021-32804
Desc: The npm package "tar" (aka node-tar) before versions 6.1.1, 5.0.6,
4.4.14, and 3.3.2 has a arbitrary File Creation/Overwrite vulnerability due to
insufficient absolute path sanitization. node-tar aims to prevent extraction of
absolute file paths by turning absolute paths into relative paths when the
`preservePaths` flag is not set to `true`. This is achieved by stripping the
absolute path root from any absolute file paths contained in a tar file. For
example `/home/user/.bashrc` would turn into `home/user/.bashrc`. This logic
was insufficient when file paths contained repeated path roots such as
`////home/user/.bashrc`. `node-tar` would only strip a single path root from
such paths. When given an absolute file path with repeating path roots, the
resulting path (e.g. `///home/user/.bashrc`) would still resolve to an absolute
path, thus allowing arbitrary file creation and overwrite. This issue was
addressed in releases 3.2.2, 4.4.14, 5.0.6 and 6.1.1. Users may work around
this vulnerability without upgrading by creating a custom `onentry` method
which sanitizes the `entry.path` or a `filter` method which removes entries
with absolute paths. See referenced GitHub Advisory for details. Be aware of
CVE-2021-32803 which fixes a similar bug in later versions of tar.
Link: https://nvd.nist.gov/vuln/detail/CVE-2021-32804
Severity: HIGH
CVE-2021-37701
Desc: The npm package "tar" (aka node-tar) before versions 4.4.16, 5.0.8, and
6.1.7 has an arbitrary file creation/overwrite and arbitrary code execution
vulnerability. node-tar aims to guarantee that any file whose location would be
modified by a symbolic link is not extracted. This is, in part, achieved by
ensuring that extracted directories are not symlinks. Additionally, in order to
prevent unnecessary stat calls to determine whether a given path is a
directory, paths are cached when directories are created. This logic was
insufficient when extracting tar files that contained both a directory and a
symlink with the same name as the directory, where the symlink and directory
names in the archive entry used backslashes as a path separator on posix
systems. The cache checking logic used both `\` and `/` characters as path
separators, however `\` is a valid filename character on posix systems. By
first creating a directory, and then replacing that directory with a symlink,
it was thus possible to bypass node-tar symlink checks on directories,
essentially allowing an untrusted tar file to symlink into an arbitrary
location and subsequently extracting arbitrary files into that location, thus
allowing arbitrary file creation and overwrite. Additionally, a similar
confusion could arise on case-insensitive filesystems. If a tar archive
contained a directory at `FOO`, followed by a symbolic link named `foo`, then
on case-insensitive file systems, the creation of the symbolic link would
remove the directory from the filesystem, but _not_ from the internal directory
cache, as it would not be treated as a cache hit. A subsequent file entry
within the `FOO` directory would then be placed in the target of the symbolic
link, thinking that the directory had already been created. These issues were
addressed in releases 4.4.16, 5.0.8 and 6.1.7. The v3 branch of node-tar has
been deprecated and did not receive patches for these issues. If you are still
using a v3 release we recommend you update to a more recent version of
node-tar. If this is not possible, a workaround is available in the referenced
GHSA-9r2w-394v-53qc.
Link: https://nvd.nist.gov/vuln/detail/CVE-2021-37701
Severity: HIGH

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://lists.rosalinux.ru/pipermail/bugs/attachments/20230503/5486418a/attachment.html>