Bug 1211842 (CVE-2023-30571)

Summary: VUL-0: CVE-2023-30571: libarchive: race condition in multi-threaded use of archive_write_disk_header() on posix based systems
Product: [Novell Products] SUSE Security Incidents Reporter: Gabriele Sonnu <gabriele.sonnu>
Component: IncidentsAssignee: Security Team bot <security-team>
Status: NEW --- QA Contact: Security Team bot <security-team>
Severity: Minor    
Priority: P3 - Medium CC: security-team
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
URL: https://smash.suse.de/issue/367776/
Whiteboard: CVSSv3.1:SUSE:CVE-2023-30571:3.9:(AV:L/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N)
Found By: Security Response Team Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Gabriele Sonnu 2023-05-31 07:07:49 UTC 
CVE-2023-30571

Libarchive through 3.6.2 can cause directories to have world-writable permissions. The umask() call inside archive_write_disk_posix.c changes the umask of the whole process for a very short period of time; a race condition with another thread can lead to a permanent umask 0 setting. Such a race condition could lead to implicit directory creation with permissions 0777 (without the sticky bit), which means that any low-privileged local user can delete and rename files inside those directories.

https://groups.google.com/g/libarchive-announce
https://github.com/libarchive/libarchive/issues/1876

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-30571
https://bugzilla.redhat.com/show_bug.cgi?id=2210921
https://www.cve.org/CVERecord?id=CVE-2023-30571
https://github.com/libarchive/libarchive/issues/1876
https://groups.google.com/g/libarchive-announce
Comment 1 Gabriele Sonnu 2023-05-31 07:10:05 UTC 
No patch yet.
Comment 2 Marcus Meissner 2023-12-20 10:50:07 UTC 
the window is super small:

libarchive/archive_write_disk_posix.c:        umask(a->user_umask = umask(0));


a workaround might be to code this according to man 2 umask:

       Since  Linux  4.7, the umask of any process can be viewed via the Umask field of /proc/[pid]/status.  Inspecting this field in /proc/self/status allows a process to retrieve its umask without at the same time changing it.

although it would really better if someone invents a new syscall for it or overloads umask itself ;)


I am tempted to ignore this issue due to the small window.
Comment 3 Danilo Spinella 2024-01-12 15:39:08 UTC 
This issue is being ignored because it's not a libarchive bug but rather an issue with its usage. See the following for more context:

https://github.com/openembedded/openembedded-core/commit/ffa8f92aa6f8405d8fea117af2f212ba190de393