Wind River VxWorks tarExtract directory traversal vulnerability (CVE-2023-38346)

Today we publish an advisory for a specific function in Wind River's VxWorks operating system.

VxWorks is a real-time operating system used in many embedded devices in high-availability environments with high safety and security requirements. This includes important industrial, medical, airospace, networking and automotive devices. For example, NASA's Curiosity rover currently deployed on planet Mars is using Wind River's VxWorks operating system.

The vulnerability is triggered when VxWorks' tarExtract function is used on untrusted tar archive files. The official VxWorks advisory can be found on the Wind River website.


Pentagrid identified a vulnerability in VxWorks' tarExtract method affecting at least VxWorks 21.07. The function tarExtract implements tar file extraction and thereby also processes files within an archive that has relative or absolute file names. While end-user tar tools on other platforms usually stop processing an archive if not otherwise forced, the VxWorks' tarExtract proceeds with processing relative or absolute filenames. This is unexpected and also undocumented behaviour, which in general may result in a directory traversal vulnerability.


If a developer uses tarExtract without additional checks, extracting an untrusted tar file may lead to an overwrite of files outside the current working directory in the filesystem of the VxWorks operating system. If the tar processing runs under elevated privileges, tarExtract may overwrite arbitrary files in a VxWorks environment, which may then lead to a system compromise. In an embedded environment, extracting tar files likely happens during multi-file imports such as data ingestion or software/configuration update. The directory traversal may lead to a verification bypass, if a tar archive is extracted first and the verification of the content happens afterwards.

We rate the issue as a high-severity issue for devices that use the tarExtract function on untrusted user input.


  • 2023-06-05: Vulnerability noticed and research into tar behaviour started.

  • 2023-06-21: Initial contact request as requested by Wind River's PSIRT and encrypted with the published PGP key. Communication of coordinated disclosure publication date 2023-09-19.

  • 2023-06-21: Wind River PSIRT replies they can't decrypt the message and asks if we exchanged keys before. Pentagrid replied in a cleartext e-mail that we used the key from Wind River's PSIRT website.

  • 2023-06-21: Pentagrid asks in a cleartext e-mail if they were able to decrypt the message now. No response from Wind River.

  • 2023-06-28: Pentagrid asks in a cleartext e-mail for a status. Pentagrid informs Wind River that if we don't receive a response, we might publish information and will contact local authorities for communication support.

  • 2023-06-28: Wind River is not able to decrypt the message. Wind River proposes to provide Pentagrid's keys in a password protected document and provide the password in a separate document. Alternatively, to send the e-mail unencrypted. Pentagrid resends advisory in an unencrypted e-mail to PSIRT lead. PSIRT lead commits to a monthly status update. Further e-mails only sent to PSIRT lead in cleartext.

  • 2023-06-29: Wind River asks for flexibility on the disclosure deadline. An hour later Wind River asks to ignore the request.

  • 2023-07-15: CVE-2023-38346 was assigned by MITRE.

  • 2023-07-17: Status update by Wind River: Analysis ongoing.

  • 2023-07-17: Wind River asks for a meeting.

  • 2023-07-31: Video call between Pentagrid and Wind River. Wind River rates the vulnerability with a CVSS 3.1 score of 6.5 (Medium). Target version for a fix is 23.09. They are working on updating the documentation and introduce a secure default behavior of tarExtract. A communication plan for customers before coordinated disclosure date is in place.

  • 2023-08-28: Video call between Pentagrid and Wind River, status update.

  • 2023-09-13: Video call between Pentagrid and Wind River, status update.

  • 2023-09-19: Coordinated disclosure, Wind River publishes their adisory.

Affected Components

The issue affects VxWorks' tarExtract method affecting in at least VxWorks 21.07. Pentagrid assumes that all VxWorks versions released before September 2023 are affected.

It is unknown to Pentagrid which or how many embedded devices implement a data ingestion or software/configuration update function by parsing untrusted archives with tarExtract. It is likely that many devices are affected, as there seems to be no other data ingestion functionality available in the VxWorks Kernel API.

CVE-2023-38346 has been assigned to this issue. The official VxWorks advisory can be found on the Wind River website.

Background information

This finding is about different expectations and assumptions when using a tar extraction function. If there is a mismatch regarding the expectations and the actual behaviour, this might lead to a security issue.

First of all, the standard tar utilities present in Linux, FreeBSD and also Busybox will not extract a file from an archive, if the file has an absolute file name or a relative file name outside the unpacking directory. Instead, these tools show a warning. For GNU and BSD tar, the option --absolute-names (-P) must be added to force extraction of such files. For example, one may expect that extracting an archive in the download folder hopefully does not overwrite a user's ~/.bashrc.

Furthermore, if an archive is extracted from the root directory (/), all path names are relative to the root directory. Files and directories may already exist and there is no need to use the pattern ../ to traverse through the filesystem. Usually, software developers expect this behaviour when applications are installed. This should be known by every software developer and can be considered expected behaviour. However, absolute paths and directory traversal paths are not expected behaviour for many software developers as the following security issues illustrate.

There were several vulnerabilities in the past regarding relative file names in tar files, for example:

The last example of Python's tarfile got a CVE-ID assigned, but is still unfixed. Many discussions about this issue can be found on the Internet. At least Python's API documentation highlights a prominent warning. But despite this warning, it seems to violate the principle of least astonishment: A researcher from Trellix rediscovered this issue, wrote a tool for automated code-analysis and estimated that there may be 340,000 repositories at Github vulnerable to the tarfile problem and this despite a documented warning. The Bitbucket and VMware vulnerabilities mentioned above are both based on the tar extractor implementation org.apache.commons.compress.archivers.tar from the Apache Commons Compress library. This library does not have a prominent warning and obviously expectations on who must take care of what failed there, too.

Bitbucket (CVE-2019-3397), Zimbra (CVE-2022-41352), vCenter (CVE-2021-21972) have CVSS Base Score beyond 9.0, implicating a critical severity. The last two vulnerabilities were added to CISA's Known Exploited Vulnerabilities Catalog. That means there is a good reason, why even a documented but unexpected behaviour becomes a problem, especially in security-critical environments.

While the above list is about tar archives, the same problem exists for many archive formats, for example:

Technical Details

Extracting untrusted user-supplied tar files in an embedded device is part of a user-friendly way to implement a multi-file import such as data ingestion or software/configuration update. The device allows tar import instead of multiple files, to simplify the process for the user. At the same time, overwriting or adding an attacker-supplied file to a file system might lead to direct remote command execution vulnerability (e.g. by overwriting an application binary that includes executable code). Therefore, many implementations of software/configuration update functions in commercial products verify the supplied files (e.g. by using cryptographic signatures). But these signatures have to be stored somewhere and therefore are usually included in the tar file. As tar file extraction therefore has to happen in a first step (to extract the cryptographic signature and the update files) and before any content is verified, the current behaviour of tarExtract allows to bypass such verification steps as well.

Documentation and source code at least for VxWorks 5.5 and 6.6 does not mention required steps to process a tar file in order to prevent vulnerabilities. It does not include warnings for the tarExtract function and that it shouldn't be applied to untrusted tar files. It also does not include a guide on how a multi-file import, such as data ingestion or software/configuration update via a single archive file (zip, tar, etc.), could be securely implemented. Tar is the only archive format currently supported according to the VxWorks Kernel API documentation.

Therefore, Pentagrid assumes that many current implementations of data ingestion or software/configuration update functions in devices with VxWorks have this vulnerability.

As privilege separation via different users in VxWorks was only recently introduced, it is possible that current implementations do not already use this feature. Therefore, it is possible that data ingestion or software/configuration update functions do not protect themself by using different users and access permissions on the operating system level.

As VxWorks tarToc function only prints to standard output, software developers would need to write custom parsers to check that the tar contents are safe to unpack. This introduces undesired complexity and dependency on the tarToc output format not changing between VxWorks versions.

Exploitation of the tarExtract issue can be achieved by supplying a crafted tar file. For creating such a tar file, Pentagrid used a simple script based on the Python version 3 tarfile library, which is flexible regarding the handling of relative file names as mentioned earlier. The used script is shown below:

#!/usr/bin/env python3
# The author of this code is not responsible for any damage caused by the use
# or misuse of this PoC exploit. This PoCs is intended for educational and
# research purposes only, and should never be used to target or exploit systems
# without explicit permission from the owner.
import tarfile
import os
with open("emptyfile", "wb") as f:
    f.write(b"Just a test")
tar_out ="example.tar", "w", format=tarfile.GNU_FORMAT)
tar_out.add("emptyfile", arcname="../TRAVERSAL")


Program code that passes an untrusted tar file to the VxWorks tarExtract function has to be present, meaning the developers must have been unaware of the implications of unpacking untrusted tar files.


User recommendation:

  • To apply the patch/update supplied by Wind River.

  • It is recommended to do integrity/authenticity checks (e.g. cryptographic signature checks) on the tar file before it is extracted to make sure it is of trusted origin where possible. We are aware that in practice this is not user friendly as the signature would need to be stored separately in another file next to the tar file. It might be feasible to append the signature to the tar file and remove it before checking the tar, but this could result in non-standard tar files.

  • It is recommended to check tar file contents by using a third-party library or custom code. It is not reommended to use the VxWorks tarToc kernel function as it will only print to stdout, which makes it impractical for further processing.

The original recommendations for Wind River were:

  • It is recommended to implement file name filtering to follow the best-practise of simplifying safe and secure library usage, while improper use of a library should be made more difficult, for example by adding an explicit force parameter to process insecure filenames.

  • It is recommended to add a clear statement in the documentation and API reference documentation if tarExtract is safe to be used with untrusted tar files or not.

  • It is recommended to consider how customers of Wind River could be supported in the future by providing more high-level APIs that provide secure data ingestion or software/configuration update functions that include signature checks.

  • It is recommended to inform Wind River's customers about the vulnerability.


The vulnerability has been found by Tobias Ospelt and Martin Schobert of Pentagrid. Pentagrid would like to thank Wind River for the support during the coordinated disclosure process.