Vulnerabilità aggiungendo un repository di pacchetti non affidabile

Question

Vulnerabilità aggiungendo un repository di pacchetti non affidabile

#1 da (2 voti)
#2 da (0 voti)

2

Spesso gli utenti installano repository di pacchetti aggiuntivi nelle loro distribuzioni Linux per poter seguire versioni "bleeding-edge" di software che non sono state / non saranno mai trasferite nella loro versione di distribuzione.

Supponiamo che packageA fornito da repoA dipenda da libssl . In origine, nessun problema riscontrato; l'unica vulnerabilità possibile dovrebbe essere fornita direttamente da packageA .

Tuttavia, se il proprietario del repository pacchetti libssl e lo include nel proprio repository (ho visto cose simili in the wild), il mio sistema libssl verrà sostituito da la loro versione compilata di OpenSSL.

Con questo detto, quanto è difficile farlo? I gestori di pacchetti (ad esempio apt, yum) forniscono protezione contro questo? Per quanto ne sappia l'utente, un repository malevolo potrebbe pacchettizzare un rootkit in un pacchetto chiamato libssl che di fatto non fornisce alcun supporto SSL. Se capisco correttamente, se questo dovesse accadere, l'utente non riceverebbe alcuna indicazione che ciò stava accadendo, e la loro macchina sarebbe stata compromessa con un semplice apt-get upgrade .

updates

posta Naftuli Kay 30.06.2014 - 21:45

fonte

2 risposte

Leggi altre domande sui tag updates

Pannello di accesso separato per gli amministratori? Come rilevare se un utente ha effettuato l'accesso a un sito Web specifico?

score 2 · Answer 1

Come regola generale, la maggior parte dei gestori di pacchetti ti chiederà se vuoi installare le dipendenze, oltre a chiedere se desideri installare pacchetti (versioni di) differenti.

Ogni volta che scarico un pacchetto da qualche parte che non è un repository di Debian (io uso Crunchbang Linux), installerò da solo le dipendenze necessarie e useremo solo il repository di terze parti per il pacchetto specifico che voglio.

In seguito, commenterò la riga nel mio file sorgenti che ha il repository di terze parti, quindi quando eseguo 'apt-get update' non otterrò nulla da quel repository. (L'unico svantaggio è che richiede un passaggio aggiuntivo per aggiornare il pacchetto da quel repository.)

Di solito quando esegui l'aggiornamento o l'upgrade ti verranno mostrati tutti i pacchetti che devono essere aggiornati. Se presti attenzione, noterai qualcosa di funky in corso.

Modifica: trovato un esempio quando provi ad aggiornare Mono

Need to get 55.8 MB of archives.
After this operation, 33.8 MB of additional disk space will be used.
Do you want to continue [Y/n]? Y
**WARNING: The following packages cannot be authenticated!**
  mono-complete mono-runtime-sgen mono-devel mono-dmcs...

Proviene da una fonte non Debian, quindi l'avviso e mi costringe a selezionare nuovamente Y .

score 0 · Answer 2

In sostanza, la preoccupazione sollevata è valida.

Il venditore di packageA potrebbe rilasciare una versione di libssl superiore alla versione della tua distribuzione di libssl . La prossima volta che aggiornerai libssl verrà installato il pacchetto (più recente) da repoA . E / o il venditore di packageA potrebbe far dipendere il proprio pacchetto dalla propria versione di libssl .

La fase di attenuazione manuale annotata da @Eric Lagergren è certamente legittima. Tuttavia, ci sono 2 passaggi che puoi intraprendere per evitare l'inconveniente di dover aggiustare manualmente l'elenco delle fonti ogni volta che vuoi aggiornare ed evitare il rischio di dimenticare, pur avendo un po 'di mente. Non sono infallibili e possono ancora essere annullati, tuttavia è ancora un miglioramento IMO.

Quando aggiungi il repository, NON utilizzare l'aggiunta di apt-key. Invece, metti la chiave del repository di terze parti da qualche altra parte. Per esempio. /usr/share/keyrings/3rd-party-key.gpg e usa una linea sources.list che assomiglia a questa:

deb [signed-by = / usr / share / keyrings / 3rd-party-key.gpg] http ...
Assicurati di bloccare tutti i pacchetti dal repository (diverso da quello / quelli che desideri installare) a bassa priorità (ad esempio 100). I pacchetti specifici che desideri installare possono essere aggiunti a un numero più alto che consentirà l'installazione (ad es. 500 +).

I dettagli di questa configurazione (e i rimanenti vettori di attacco) sono indicati nella wiki di Debian . Anche sul wiki di Debian, un'altra pagina discute una potenziale risoluzione dei dettagli di ulteriori problemi sollevati qui (wiki di Debian di nuovo ...).