A bug lurking for 12 years gives attackers root on most major Linux distros
Since 2009, pkexec has contained a memory-corruption vulnerability that people with limited control of a vulnerable machine can exploit to escalate privileges all the way to root. Exploiting the flaw is trivial and, by some accounts, 100 percent reliable. Attackers who already have a toehold on a vulnerable machine can abuse the vulnerability to ensure a malicious payload or command runs with the highest system rights available. PwnKit, as researchers are calling the vulnerability, is also exploitable even if the Polkit daemon itself isn’t running. PwnKit was discovered by researchers from security firm Qualys in November and was disclosed on Tuesday after being patched in most Linux distributions. PwnKit is tracked as CVE-2021-4034. [...] Major Linux distributors have released patches for the vulnerability, and security professionals are strongly urging administrators to prioritize installing the patch. Those who can’t patch immediately should use the chmod 0755 /usr/bin/pkexec command to remove the SUID-bit from pkexec, which prevents it from running as root when executed by a non-privileged user. Advisories from Debian, Ubuntu, and Red Hat are here, here, and here. Those who want to know if the vulnerability has been exploited on their systems can check for log entries that say either “The value for the SHELL variable was not found the /etc/shells file” or “The value for environment variable […] contains suspicious content.” Qualys, however, cautioned people that PwnKit is also exploitable without leaving any traces. Continua su https://arstechnica.com/information-technology/2022/01/a-bug-lurking-for-12-... Insomma non temete: dopo 12 anni dalla sua introduzione, questa vulnerabilità è stata corretta entro poche ore dalla propria diffusione pubblica. Giacomo
Buongiorno Giacomo, Giacomo Tesio <giacomo@tesio.it> writes: [...]
Attackers who already have a toehold on a vulnerable machine can abuse the vulnerability to ensure a malicious payload or command runs with the highest system rights available.
proprio per non sminuire la portata del bug, direi che la frase "Attackers who already have a toehold" è quantomeno sibillino forse le parole di chi ha pubblicato per primo il bug report aiutano a comprendere la natura e l'estensione della sua pericolosità: https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt --8<---------------cut here---------------start------------->8--- pwnkit: Local Privilege Escalation in polkit's pkexec (CVE-2021-4034) [...] This vulnerability is an attacker's dream come true: - pkexec is installed by default on all major Linux distributions (we exploited Ubuntu, Debian, Fedora, CentOS, and other distributions are probably also exploitable); - pkexec is vulnerable since its creation, in May 2009 (commit c8c3d83, "Add a pkexec(1) command"); - any unprivileged local user can exploit this vulnerability to obtain full root privileges; - although this vulnerability is technically a memory corruption, it is exploitable instantly, reliably, in an architecture-independent way; - and it is exploitable even if the polkit daemon itself is not running. --8<---------------cut here---------------end--------------->8--- quindi in qualche modo l'attaccante deve riuscire a ottenere accesso come local user, magari sfruttando vulnerabilità di altri servizi esposti online [...]
Insomma non temete: dopo 12 anni dalla sua introduzione, questa vulnerabilità è stata corretta entro poche ore dalla propria diffusione pubblica.
...mentre dopo 50 anni dall'introduzione del C sarà ancora possibile scrivere codice che esegue accesso alla memoria "out of bounds" senza che chi lo scrive e chi lo legge si renda conto di quel fatto? :-O già discusso qui: https://server-nexa.polito.it/pipermail/nexa/2020-May/017979.html (la madre di tutte le vulnerabilità: memory unsafety) tra 30 anni saremo ancora a questo livello? Ciao, 380° -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
Ciao Giovanni, On January 27, 2022 5:52:25 PM UTC, "380°" <g380@biscuolo.net> wrote:
Insomma non temete: dopo 12 anni dalla sua introduzione, questa vulnerabilità è stata corretta entro poche ore dalla propria diffusione pubblica.
...mentre dopo 50 anni dall'introduzione del C sarà ancora possibile scrivere codice che esegue accesso alla memoria "out of bounds" senza che chi lo scrive e chi lo legge si renda conto di quel fatto? :-O
siamo sicuri che il problema sia il sempre bistrattato C? O è piuttosto la complessità di Linux? Leggi la discussione sul fix lato kernel (fix di due righe!): ``` The first argument to argv when used with execv family of calls is required to be the name of the program being executed, per POSIX. By validating this in do_execveat_common(), we can prevent execution of shellcode which invokes execv(2) family syscalls with argc < 1, a scenario which is disallowed by POSIX, thus providing a mitigation against CVE-2021-4034 and similar bugs in the future. The use of -EFAULT for this case is similar to other systems, such as FreeBSD and OpenBSD. Interestingly, Michael Kerrisk opened an issue about this in 2008, but there was no consensus to support fixing this issue then. Hopefully now that CVE-2021-4034 shows practical exploitative use of this bug in a shellcode, we can reconsider. ``` https://lore.kernel.org/lkml/20220126043947.10058-1-ariadne@dereferenced.org... Leggi le due righe del fix. Si passa da ``` if (retval < 0) goto out_free; ``` a ``` if (retval < 1) { retval = -EFAULT; goto out_free; } ``` Pensi che se fosse stato scritto in Rust, o Haskell o qualsiasi altro linguaggio avrebbe fatto qualsivoglia differenza? Ipotizza un mondo dove C è stato sostituito dal tuo linguaggio di programmazione preferito. In user space non avresti avuto l'out of bound. Poco male: poche righe di assembly e bypassi i limiti del tuo linguaggio. Il compilatore impedisce (coraggiosamente!) codice unsafe? Ok, scriviamo l'elf con un editor esadecimale. Il problema non è C. (almeno, non in questo caso) Piuttosto, vogliamo davvero fingere che la segnalazione di Michael Kerrisk sia stata ignorata da intelligence che hanno team dedicati e database degli zero day ignoti? Su quanti server Linux queste intelligence hanno accesso amministrativo dal 2008? Quante distro Linux vengono distribuite da server Linux? Quanti cloud ci girano? Non ho idea se nel 2008 abbiano lasciato la vulnerabilità perché non immaginavano come sfruttarla, o se non si sia trovato un consenso perché qualcuno l'aveva subito capito. Ma se vogliamo che fra 30 anni le cose vadano meglio, non accontentiamoci di facili capri espiatori. Giacomo Full disclosure: programmo in moltissimi linguaggi e considero C99 il "meno peggio".
participants (2)
-
380° -
Giacomo Tesio