[Soci SLIP] Red Hat, Ubuntu, and Arch Linux patch Linux kernel exploit

[loredana]

On 1/19/13, Lucio Crusca <lucio a sulweb.org> wrote:
> In data sabato 19 gennaio 2013 14:36:28, loredana ha scritto:
>> Red Hat, Canonical, and Arch Linux hanno rilasciato le pezze per una
>> vulnerabilità dei kernels Linux dalla release 2.6.39 in sù  che
>> permette ad un attaccante di ottenere l'accesso ad un sistema come
>> root (via su e, quindi, anche sudo):
>
> La notizia andrebbe un po' ridimensionata, perché detta così rischia di
> seminare terrore.
>
> La vulnerabilità è sfruttabile solo se:
>
> 1. si possiede un account di sistema (ovvero non è sfruttabile da remoto)
> 2. la funzionalità ASLR del kernel non è attiva (ma è attiva di default fin
> dal kernel 2.6.12, quindi è necessario che il sysadmin l'abbia disattivata
> volontariamente)
>

Per cortesia, ci dici da dove ricavi le tue informazioni? Da:
     http://blog.zx2c4.com/749
cioè dal link con i dettagli tecnici raggiungibile dirattamente dalla
pagina che avevo segnalato, io traggo conclusioni ben diverse dalle
tue. Leggere direttamente i codice e
verificare è sempre meglio di qualsiasi blog.

Cito:
[...]
There is one remaining objection. Where do we write to? We have to
lseek to the proper memory location before writing, and ASLR
randomizes processes address spaces making it impossible to know where
to write to. Should we spend time working on more cleverness to figure
out how to read process memory, and then carry out a search? No. Check
this out:

$ readelf -h /bin/su | grep Type
  Type:                              EXEC (Executable file)

This means that su does not have a relocatable .text section
(otherwise it would spit out “DYN” instead of “EXEC”). It turns out
that su on the vast majority of distros is not compiled with PIE,
disabling ASLR for the .text section of the binary! So we’ve chosen su
wisely. The offsets in memory will always be the same. So to find the
right place to write to, let’s check out the assembly surrounding the
printing of the “Unknown id: blabla” error message.
[..]

Traduco velocemente solo la parte rilevante: Succede che la stragrande
maggioranza delle distribuzioni GNU/linux non è compilata com PIE e
disabilita ASLR per la sezione .text del binario!

Ergo, non ci vuole nessuno che fa il debug per disabilitare ASLR per
su (e sudo), lo fanno le distribuzioni (non debian e non tutte).

> Inoltre si tenga conto che
> 1. i sistemi dove un eventuale attaccante potrebbe avere un account locale
> sono i server. Sui sistemi client l'attaccante al limite può riuscire a far
> eseguire qualcosa al nostro PC solo se riesce a sfruttare prima qualche
> altra
> vulnerabilità.
> 2. l'unico motivo che vedo per disabilitare l'ASLR potrebbe essere quello di
> voler debuggare un software sviluppato in assembler o al limite in C, cosa
> che di sicuro nessuno fa su un server (il debug intendo) e ad oggi in pochi
> fanno
> anche sui client (lo sviluppo in assembler/C). Di questi pochi, ancora meno
>
> (forse nessuno) ha una necessità reale di disabilitare l'ASLR.

Ma come vedi, non è quello il punto per su (e sudo) e quanti utenti usano sudo?
Senza contare che utenti GNU/inux con password di root uguale al
proprio nome non mancano :) Quanto ci vuole a "bucare" una di quelle
macchine? Tu quanto ci metteresti?

>>
>> http://www.linuxfordevices.com/c/a/News/CVE20120056-patched/
>>
>> I sistemi sono rimasti esposti per un bel po' prima che le patch
>> raggiungessero gli utenti
>
> Sì, però esposti ad un rischio più teorico che reale, ovvero vulnerabili
> solo
> se il sysadmin per intervenuta follia decide di digitare il seguente comando
>
> per disabilitare l'ASLR:
>
> # echo 0 > /proc/sys/kernel/randomize_va_space

Non è così, vedi sopra, il rischio c'è stato, eccome.

>> Exploit migrates to Android 4.0
>
> Anche su Android l'ASLR è attivo di default (ho verificato). Qui però
> diciamo
> che il rischio è leggermente più alto, perché nella maggior parte dei casi è
>
> impossibile aggiornare il kernel, quindi la vulnerabilità resta lì e magari
> il
> proprietario del telefono disattiva l'ASLR nel tentativo di debuggare un
> driver che sta sviluppando (per fare debug delle normali app non serve
> disabilitare ASLR) e contestualmente installa una app maligna di terze
> parti.
> Dobbiamo però immaginare uno sviluppatore di drivers per smartphone Android
>
> che si fa fregare da uno script kiddie... alla peggio lo sviluppatore sarà
> comunque in grado di reinstallarsi il telefono.

Va beh, se pensi che tutto sia così facile, il mondo così accorto,
l'utente così al sicuro..
Lasciami dire, senza entrare in una discussione infinita, e
possibilmente senza riferimenti ai miei incubi personali, che io non
credo affatto che sia sano ideologicamente minimizzare sempre tutto.

> Il tutto per dire che ogni giorno vengono scoperte vulnerabilità ben più
> pericolose di questa, ma non riguardando il kernel non fanno notizia.

Questa era ben pericolosa. Quanti danni abbia fatto, non lo so.

> Ciò detto, sono comunque d'accordo che un kernel patchato sia meglio di uno
> vulnerabile.

Anch'io :)

Loredana