Hello,
Based on the issues related to CVE-2023-7216, I would like to discuss with the Red Hat community. I have summarized my viewpoints from the previous emails and listed them as follows:
1.cpio maintainer does not consider this to be a CVE. The maintainer's response in the email was as follows:
> First of all, I would like to confirm with you, do you accept
> CVE-2023-7216? Is CVE-2023-7216 a bug or is it the default
> behavior of cpio software?
It is a normal behavior. Please use the --no-absolute-filenames option to avoid it, if it is not desired.
In fact, as early as the discussions related to CVE-2015-1197, the maintainer shared his perspective on this vulnerability, stating that the phenomenon mentioned in CVE-2023-7216 is consistent with his expected behavior. His exact words were “If it already contains symbolic links, some users expect that those links are followed because they have used symlinks to move part of the file system tree to somewhere else (perhaps a large file system).” For more details, please refer to the following two links:
https://www.openwall.com/lists/oss-security/2015/01/07/5 and
https://www.openwall.com/lists/oss-security/2015/01/08/4 .
This is also described in the official cpio manual (
https://www.gnu.org/software/cpio/manual/cpio.pdf ), the exact words are:“ Extracting an archive requires a bit more thought. First of all, by default cpio extracts the files with exactly the same name as stored in the archive. That means that if the archive contains absolute paths, you will extract files to their absolute locations no matter what directory you’re in when running the command. You can instruct cpio to remove leading slashes using the ‘--no-absolute-filenames’ option. Nevertheless, the good practice is to always test the archive using cpio -t prior to extracting it.”
Therefore, should the Red Hat community seriously consider marking CVE-2023-7216 as rejected on NVD?
2. I have also reproduced the POC you provided, and our results are as follows:
• When the attacker does not have read and write permissions for the attack directory, this attack scenario cannot be carried out.
``` root
[root@locathost /] ls -l |grep dirA
drwx----- 2 root root 4096 Mar 6 17:52 dirA
[root@locathost /]#
[root@locathost /]#
```
```userA
[userA@Localhost ~]$ cpio -vt < trav.cpio
lrwxrwxrwx 1 root root 6 Mar 15:15 tmp -> /dirA/
-rw------ 1 root root 15 Mar 15:15 tmp/trav.txt
block
[userA@Localhost ~]$ cpio -i < trav.cpio
cpio: tmp/trav.txt: Cannot open: Permission denied
1 block
[userA@Localhost ~]$
```
• When there is already a file with the same name in the attack directory, cpio has a protection mechanism and cannot cause critical file overwrite.
``` root
[root@localhost /]# cat /tmp/trav.txt
111
```
```userA :The content of tmp/trav.txt in the cpio is "TEST Traversal".
[userA@Localhost ~]$ cpio -vt < travsed.cpio
lrwxrwxrwx 1 root root 5 Feb 27 18:55 tmp -> /tmp/
-rw------- 1 root root 15 Feb 27 18:56 tmp/trav.txt
l block
[userA@Localhost ~]$ cpio -i< travsed.cpio
cpio: tmp/trav.txt not created: newer or same age version exists
1 block
```
Based on the reproduction results, I believe that even if this vulnerability is considered a CVE, its impact is limited. Why does it have a score of 8.8? In comparison, CVE-2023-7207 has a score of only 4.8 (
https://nvd.nist.gov/vuln/detail/CVE-2023-7207 ). Both vulnerabilities leverage symbolic links for path traversal attacks, and the methods and effects of the attacks are the same. Why is there such a large discrepancy in the scores between the two CVEs? I look forward to your explanation and hope you can provide the basis for each CVSS score.
3. Also, I see that the Red Hat community does not intend to fix this CVE vulnerability (
https://access.redhat.com/security/cve/cve-2023-7216 ). What are the subsequent mitigation measures? Currently, it seems that the community maintainer will not address this issue. Should the Red Hat community respect the maintainer's wishes and consider this an expected behavior by default, rather than treating it as a CVE vulnerability?
looking forward to your reply! Wish you a good day!
Best regards,
Peng