lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <84c507d6-4cca-4ae2-a2e7-aae27eeecc4a@evolution-hosting.eu>
Date: Wed, 10 Jan 2024 12:11:41 +0100
From: fulldisclosure <fulldisclosure@...lution-hosting.eu>
To: fulldisclosure@...lists.org
Subject: Re: [FD] cpio privilege escalation vulnerability via setuid files
 in cpio archive

Am 08.01.24 um 10:25 schrieb Georgi Guninski:
> One example is r00t extracts to/tmp/  and scidiot runs /tmp/micq/backd00r
> without further interaction from root.
>
> We believe this is vulnerability, since directory traversal in cpio
> is considered vulnerability.

It's not a vulnerability, as

a) cpio archives must archive that flag as cpio is part of RPM packages 
and those
must be able to contain setuid flags. Otherwise, you would need to add 
chmod u+s  cmds to any %POST
section. Breaking this, would invalidate so many existing packages => 
won't happen

note: initramfs makes use of cpio as well, but setuid is not needed 
here, as it's already running as root

b) it's not cpio's fault, if roidiot unpacks (insecure) archives as root 
to "public" available places.

c) If you consider "keeping the file flags intact" a vulnerability, you 
would also consider TAR as vulnerable:

as root:

# cd /tmp/
# touch setuid.sh
# chmod u+srwx setuid.sh
# tar cv setuid.sh | tar x -C tmp/
setuid.sh
# ls -ls tmp/
insgesamt 0
0 -rwsr--r--. 1 root root 0 10. Jan 11:55 setuid.sh

You could not backup your system correctly anymore, if  TAR would change 
this, as setuid files could be valid for your system.

The archivsofware isn't the issue here, as it's neutral technology. In 
this case, the admin has to keep this in mind and not unpack a potential 
risky piece of software to a user available place.
best regards,
Marius Schwarz
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ