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:
?6?1 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 ~]$
```
?6?1 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
