Come posso patchare la vulnerabilità dello shellshock su un sistema Ubuntu obsoleto che non posso aggiornare?

22

Ho un sistema che gestisco da remoto (a 2 fusi orari) che esegue Ubuntu 9.04, Jaunty. Per vari motivi, principalmente che sono davvero diffidente nel provare a fare un aggiornamento della distribuzione da così lontano, non riesco ad aggiornarlo a una versione più recente. Ovviamente non è più supportato e non ci sono patch ufficiali. Sono disponibili istruzioni su come posso correggere il codice e ricompilare me stesso per rimuovere le vulnerabilità dello shellshock?

— Claus
fonte

5

Che ricerca hai fatto su questo argomento? La soluzione più semplice sarebbe probabilmente ricostruirla e patcharla da soli. Potrebbe essere necessario accettarlo semplicemente per aggiornare il server.

— Ramhound,

Sì, questa è la mia opzione di fallback. Il server sta per uscire, sto solo cercando di tenerlo zoppicando finché non arrivano i fondi per la sua sostituzione. Se fossi sul posto, morderei il proiettile e farei l'aggiornamento, ma molto raramente lo faccio senza intoppi e senza essere in grado di metterlo sulle mani preferirei non rischiare che se non avessi a.

— Claus

Basta ottenere alcune parole chiave sulla pagina in modo che le persone possano trovarlo. Ha funzionato anche per me su Mac, OS X, Mavericks in base al test pubblicato su arstechnica.com/security/2014/09/…

1

lasciatelo senza patch, "zoppicando" cambierà rapidamente. Sii molto chiaro, stai usando una distro che è uscita cinque anni fa . Il supporto è terminato nell'ottobre 2010. Hai molte più vulnerabilità di cui preoccuparti.

— tedder42,

29

L' ho rubato da AskUbuntu , da qualcuno che l'ha rubato a Hacker News. Ho lavorato su due vecchi server per me

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 1 28); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 1 28);do patch -p0 < ../bash43-$i; done
#build and install
./configure --prefix=/ && make && make install
cd .. 
cd ..
rm -r src

Aggiornamento: ho appena notato che se non aggiungi --prefix=/al comando configure finirai con /usr/local/bin/bashquello che è aggiornato e /bin/bashsarà comunque vulnerabile.

— unkilbeeg
fonte

C'è un bug nello script: la sequenza "0 25" dovrebbe essere "1 26". Se stai leggendo questo e sei in grado di modificare la risposta, ti preghiamo di aggiornarla. Grazie!

— joelparkerhenderson,

Mentre le ./configure --prefix=/ && makepiste vanno bene, make installsembra che richiedanosudo

— Stewart,

Grazie per averlo pubblicato, un modo equo per correggere le cose durante la migrazione. Alcune persone hanno molte vms e non è realistico ricostruire ognuna. Utilizzare questo come una soluzione immediata mentre risolverlo più a lungo termine essendo su un'installazione più aggiornata è la chiave.

— Jas Panesar,

@ rubo77 Adesso deve essere 1 27 (la nuova patch 27 è la più importante)

— joelparkerhenderson

1

Aggiunta di patch 28. Ciò non sembra risolvere il CVE-2014-7186 / 7187 vulnerabilità.

— unkilbeeg,

2

C'è anche una soluzione per aggiornare il tuo sources.list a quello più recente e quindi usare apt-get per aggiornare solo bash. È molto veloce e ho scritto un articolo a riguardo. Ecco cosa fai praticamente:

Esegui l'upgrade ai più recenti repository apt-get di Ubuntu (potresti anche dover modificare gli URL old-repositories.ubuntu.com se li usi, consulta l'articolo collegato):

sudo sed -i 's/YOUR_OS_CODENAME/trusty/g' /etc/apt/sources.list

Aggiorna bash / applica correzione:

sudo apt-get update
sudo apt-get install --only-upgrade bash

E possibilmente cambiare nuovamente i repository apt-get.

— Erik Duindam
fonte

Ha funzionato perfettamente!

— Peter Kruithof,

-1

Il comando dovrebbe essere

sudo apt-get update && sudo apt-get install --only-upgrade bash

— ColdenZero
fonte

2

Questo non aiuta; come ha detto l'OP, non è più supportato, quindi non ci sarà un aggiornamento per bash.

— Andrew Ferrier,

-3

Una semplice opzione è semplicemente non usare bash. Assicurarsi che dashsia installato e che /bin/shsia un collegamento simbolico a dash, non bash. (Questo è il valore predefinito su alcune versioni di Debian, ma non sono sicuro di Ubuntu.) Se si dispone di account utente per l'accesso ssh con comandi forzati, è necessario modificare anche le shell di login. Potrebbe anche essere necessario verificare la presenza di eventuali script esplicitamente utilizzando bash; grepping per #!/bin/bashdovrebbe trovarli.

— R ..
fonte

5

È un po 'come dire "abbiamo scoperto che puoi avere segfault in C ++, usa Java invece" ...

— DevSolar,

3

Un'analogia più stretta sarebbe dire a qualcuno che sta vivendo un bug in GCC di provare il clang. Entrambi implementano lo stesso linguaggio (con insiemi di estensioni non standard diverse ma talvolta sovrapposte) ed è improbabile che l'effettivo bisogno sia di "bash" ma piuttosto di "interprete di shell".

— R ..

Come hai detto, ci sono script che potrebbero usare esplicitamente bash. Anche se cerchi i file esistenti che usano bash, in futuro qualcuno potrebbe aggiungere un nuovo script al sistema che usa esplicitamente bash. Lo stesso vale per i sistemi embedded che usano busybox (/ bin / sh points to busybox), ma hanno anche installato bash. La cosa migliore è aggiornare bash nei sistemi vulnerabili.

— jcarballo,

La maggior parte degli script Unix / Linux richiede bash o qualche altra shell moderna come ksh o zsh. Queste hanno molte funzionalità che le persone si aspettano in qualsiasi lingua ma non sono presenti nelle shell "bare-bones" come (BusyBox) ash / Dash / sh (originale). Queste shell più semplici hanno solo il 20-30% della funzionalità delle shell più grandi che le rende più veloci. Tuttavia, richiedono l'uso estensivo di utility esterne per molte operazioni comuni come la gestione avanzata delle stringhe e la corrispondenza dei modelli. Bash e simili possono far funzionare la cenere, ecc. script. Ma non viceversa.

— DocSalvager,