Patchare il kernel della Slack 11

[Burroughs]

Scusate la domanda forse un po' banale: a casa tengo un serverino, con Slack 11 sopra, su cui sto facendo girare un'infinità di servizi ed applicazioni (cosa della quale vado orgoglioso).
Considerata la vetustà del kernel, che dovrebbe appartenere al ramo 2.6.18.x, e la pericolosità della falla di cui si discusse all'epoca qui, mi domandavo se, per rendere più sicuro il kernel che attualmente utilizzo, debba per forza installarmene un altro, magari ricorrendo ad un make oldconfig, oppure se vi sia, più semplicemente, la possibilità di patcharlo, senza sbattimenti ulteriori.

Burroughs.

[conraid]

Scusate la domanda forse un po' banale: a casa tengo un serverino, con Slack 11 sopra, su cui sto facendo girare un'infinità di servizi ed applicazioni (cosa della quale vado orgoglioso).
Considerata la vetustà del kernel, che dovrebbe appartenere al ramo 2.6.18.x, e la pericolosità della falla di cui si discusse all'epoca qui, mi domandavo se, per rendere più sicuro il kernel che attualmente utilizzo, debba per forza installarmene un altro, magari ricorrendo ad un make oldconfig, oppure se vi sia, più semplicemente, la possibilità di patcharlo, senza sbattimenti ulteriori.

Burroughs.

Devi stare attento alle glibc, se prendi uno degli ultimi kernel devi anche aggiornare glibc.
Insomma, valutali "in coppia"

[Burroughs]

Devi stare attento alle glibc, se prendi uno degli ultimi kernel devi anche aggiornare glibc.
Insomma, valutali "in coppia"

Deduco dalla tua risposta che non vi sia verso di patchare il kernel, o mi sbaglio?

Burroughs.

[conraid]

Puoi provare a vedere come e dove agisce la patch e farlo da solo. Non saprei.

Altrimenti prova questo

Temporary fix :

* Download http://www.ping.uio.no/~mortehu/disable ... loitable.c
* Compile it using gcc (so "gcc disable-vmsplice-if-exploitable.c -o rm_exploit") as normal user
* Run it as normal user
--> You are now protected until the next reboot of the system

[albatros]

Devi stare attento alle glibc, se prendi uno degli ultimi kernel devi anche aggiornare glibc.
Insomma, valutali "in coppia"

Perché? Dove lo hai letto? Compilando un kernel con glibc datate si è soggetti all'exploit ? (non ho letto tutta la discussione linkata, se è spiegato lì lo faccio)
Di solito c'è il problema inverso, ovvero usare un kernel più vecchio di quello rispetto ai cui headers sono state compilate le glibc, ma dove hai trovato scritto di una versione minima delle glibc > 2.3.6 (quella della 11) per compilare/usare le ultime versioni del kernel?

@Burroughs: Come già detto, non ho letto tutta la discussione linkata sopra, ma se l'exploit è locale e non offri shell agli avventori del tuo server, non dovresti correre rischi (a meno di altri difetti del kernel).

[conraid]

Devi stare attento alle glibc, se prendi uno degli ultimi kernel devi anche aggiornare glibc.
Insomma, valutali "in coppia"

Perché? Dove lo hai letto? Compilando un kernel con glibc datate si è soggetti all'exploit ? (non ho letto tutta la discussione linkata, se è spiegato lì lo faccio)

No, non mi sembra. Mi sono sbagliato.
ricordavo letture di quel periodo dove si diceva che vmsplice() fosse stata introdotta con le glibc 2.5, ma ho visto che nel kernel esistono codici per far si di funzionare anche senza tale funzione, altrimenti non funzionerebbe nemmeno
In questo caso, oltre al fatto che come dici tu se usa solamente lui la shell il bug non dovrebbe importare più di tanto, c'è anche la possibilità che non funzioni affatto.
Il tutto detto da "ignorante" della programmazione di sistema, quindi posso anche ricordare male o aver letto qualcosa di errato in origine

@Burroughs
Se non hai già provato, prova ad eseguire l'exploit che trovi in giro, tanto per curiosità.

[Burroughs]

@Burroughs
Se non hai già provato, prova ad eseguire l'exploit che trovi in giro, tanto per curiosità.

Sì, ho provato sia l'exploit che il workaround che mi hai suggerito tu e funzionano entrambi.
La cosa strana è che se, dopo aver riavviato la macchina, riavvio anche l'exploit (in verità ricompilo solo il file .c), ottengo questo output:

Codice: Seleziona tutto

alutri@steely:~$ gcc vulnerability.c
/usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../i486-slackware-linux/bin/ld: cannot open output file a.out: Permission denied
collect2: ld returned 1 exit status
alutri@steely:~$

Da cosa può dipendere?

Burroughs.

[conraid]

Da cosa può dipendere?

L'errore sembra di permessi
La butto li. Che c'è ancora a.out che avevi magari compilato da root?

[Burroughs]

L'errore sembra di permessi
La butto li. Che c'è ancora a.out che avevi magari compilato da root?

Sì, era un problema di permessi.
Tornando al workaround, beh, di funzionare funziona, ma nel momento in cui il sistema si riavvia anche per una banale interruzione di energia elettrica, il problema si ripresenta.
L'unica soluzione sarebbe creare uno script che esegua, ad ogni boot del sistema, quanto richiesto dal workaround, con i privilegi dell'utente semplice e in modalità unattended, cioè senza interazione alcuna.
Facile a dirsi, meno a farsi.
Ah, dimenticavo, il server pubblica i propri servizi anche su Internet, per cui il problema è abbastanza serio.

Burroughs.

[conraid]

Prova ad aggiornare il kernel o a mettere tutto in rc.local in qualche modo.
Come ti ha detto albatros il discorso delle glibc è diverso, quindi tentar non nuoce

[robbybby]

Per completezza di informazione:
la Slack 11.0 funziona tranquillamente con kernel 2.6.24.x: la sto usando in questo momento. Per la verita', sulla Slack 11 ho usato da subito i kernel della serie 2.6, senza avere nessun problema di compatibilita'.

[Burroughs]

Prova ad aggiornare il kernel o a mettere tutto in rc.local in qualche modo.[CUT]

Ho scelto la via più comoda, che è quella di applicare il workaround, solo che quando eseguo rm_exploit si richiede l'interazione dell'utente, che deve premere il tasto invio.
Ora, automatizzare tutto questo in uno script non è proprio semplicissimo.
Any ideas?

Burroughs.