Tar version 2.2.2 represents a notable update to the popular tar package for Node.js, evolving from its previous stable release, version 2.2.1. While both versions share a core purpose – providing tar archive functionality within Node.js environments – version 2.2.2 introduces key enhancements and modifications that warrant attention from developers.
A primary distinction lies in the dependencies. While both versions rely on fstream, inherits, and block-stream, version 2.2.2 specifies a newer version of fstream with "fstream":"^1.0.12", compared to "fstream":"^1.0.2" in version 2.2.1. This suggests potential improvements, bug fixes, or new features incorporated within the fstream dependency that directly impact the tar package's performance and reliability. Developers should investigate the changes in fstream between these versions to understand the implications. Also, the newer version has some extra data about the package like fileCount and unpackedSize.
Another significant difference is the release date. Version 2.2.2 was released on May 15, 2019, a considerable time jump from version 2.2.1, which was released on September 10, 2015. This four-year gap implies a period of ongoing development, bug fixing, and optimization efforts culminating in the newer release.
Developers using tar should upgrade to 2.2.2 to benefit from these improvements and ensure compatibility with the broader Node.js ecosystem. The upgrade may offer enhanced stability and performance due to the updated dependencies and accumulated refinements.
All the vulnerabilities related to the version 2.2.2 of the package
Arbitrary File Creation/Overwrite due to insufficient absolute path sanitization
Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution
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.
3.2.2 || 4.4.14 || 5.0.6 || 6.1.1
NOTE: an adjacent issue CVE-2021-32803 affects this release level. Please ensure you update to the latest patch levels that address CVE-2021-32803 as well if this adjacent issue affects your node-tar
use case.
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.
const path = require('path')
const tar = require('tar')
tar.x({
file: 'archive.tgz',
// either add this function...
onentry: (entry) => {
if (path.isAbsolute(entry.path)) {
entry.path = sanitizeAbsolutePathSomehow(entry.path)
entry.absolute = path.resolve(entry.path)
}
},
// or this one
filter: (file, entry) => {
if (path.isAbsolute(entry.path)) {
return false
} else {
return true
}
}
})
Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.
Arbitrary File Creation/Overwrite on Windows via insufficient relative path sanitization
Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution
node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain ..
path portions, and resolving the sanitized paths against the extraction target directory.
This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as C:some\path
. If the drive letter does not match the extraction target, for example D:\extraction\dir
, then the result of path.resolve(extractionDirectory, entryPath)
would resolve against the current working directory on the C:
drive, rather than the extraction target directory.
Additionally, a ..
portion of the path could occur immediately after the drive letter, such as C:../foo
, and was not properly sanitized by the logic that checked for ..
within the normalized and split portions of the path.
This only affects users of node-tar
on Windows systems.
4.4.18 || 5.0.10 || 6.1.9
There is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.
Users are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.
The fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not "absolute".
Additionally, a path starting with a drive letter and then two dots, like c:../
, would bypass the check for ..
path portions. This is checked properly in the patched versions.
Finally, a defense in depth check is added, such that if the entry.absolute
is outside of the extraction taret, and we are not in preservePaths:true mode, a warning is raised on that entry, and it is skipped. Currently, it is believed that this check is redundant, but it did catch some oversights in development.
Denial of service while parsing a tar file due to lack of folders count validation
During some analysis today on npm's node-tar
package I came across the folder creation process, Basicly if you provide node-tar with a path like this ./a/b/c/foo.txt
it would create every folder and sub-folder here a, b and c until it reaches the last folder to create foo.txt
, In-this case I noticed that there's no validation at all on the amount of folders being created, that said we're actually able to CPU and memory consume the system running node-tar and even crash the nodejs client within few seconds of running it using a path with too many sub-folders inside
You can reproduce this issue by downloading the tar file I provided in the resources and using node-tar to extract it, you should get the same behavior as the video
Here's a video show-casing the exploit:
Denial of service by crashing the nodejs client when attempting to parse a tar archive, make it run out of heap memory and consuming server CPU and memory resources
This report was originally reported to GitHub bug bounty program, they asked me to report it to you a month ago