Sì, è possibile fare un attacco di avvelenamento della cache e sì è possibile proteggersi.

Oltre alla pratica piuttosto normale di firmare i file del pacchetto con GPG, alcune distribuzioni utilizzano DNSSEC per proteggere i domini che servono tali file contro lo spoofing del DNS.

Notare il flag "annuncio" nella risposta dns di seguito:

$ dig +dnssec security.debian.org.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +dnssec security.debian.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23375
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;security.debian.org.           IN      A

;; ANSWER SECTION:
security.debian.org.    300     IN      A       212.211.132.250
security.debian.org.    300     IN      A       128.31.0.36
security.debian.org.    300     IN      A       128.61.240.73
security.debian.org.    300     IN      A       128.101.240.212
security.debian.org.    300     IN      A       149.20.20.6
security.debian.org.    300     IN      A       195.20.242.89
security.debian.org.    300     IN      A       200.17.202.197
security.debian.org.    300     IN      A       212.211.132.32
security.debian.org.    300     IN      RRSIG   A 8 3 300 20140827233402 20140728233402 28626 security.debian.org. AF84GPGaVSMwLsTWP0vVJpW6E9r7PL1Pi/LTxGXPUt5x1AxeW8UKJ+wh OiB6tPy91sBRA5GfNofq+P3AhsWt2JGSR/iiN9qq6p6ryU6G5gQeZbYY MYVGDzf3j2z+kUMbsB902L/fPeJzLDxyaJzHPLU8alzs+4bvvKfd4SeA +MyGrckpFkr0Csi2LtRKGA5hJPrxFcHOFeWsY+n/mjAxy8g6SSdYrKVZ 3kk5G9sR1kKSiyHwxFVaIQXR0j1skl9/

;; AUTHORITY SECTION:
security.debian.org.    28800   IN      NS      geo1.debian.org.
security.debian.org.    28800   IN      NS      geo2.debian.org.
security.debian.org.    28800   IN      NS      geo3.debian.org.
security.debian.org.    28800   IN      RRSIG   NS 8 3 28800 20140827233402 20140728233402 28626 security.debian.org. TpTt53QAgOwwH38oqkfbm4F07j78VthQCzcHezN+N0+fPu0vXiatFMAI 1CBAFkYj/rkYNfv+xhM7OfvNgWMcRoMn9v7UOtMdxUOsjO2lQCVdjMsx TRz9OITY/NZWVD0/hkNXvpBVbsFW+y0JRzEb0xegHdGYHS1A9PVwRlCT 2DJLgkL6mS+RrOfteEDZD80HZZiiQcDLf1CgG6K2s5wNUIwsAzZdFEWC XnCXAguK3PVusvvnHz1i09B9qducyd+8

;; Query time: 2370 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 29 04:00:11 2014
;; MSG SIZE  rcvd: 719

Per impostazione predefinita, debian (e la maggior parte delle altre distro di AFAIK) richiedono di richiedere la firma GPG per la corrispondenza.

Se vuoi sfruttare la protezione DNSSEC sui domini che servono i file del pacchetto, esegui localmente un server di nomi di cache di convalida, come ad esempio unbound o bind.

Risposta breve

• Sì è possibile e, a parte il controllo gpg, ci sono ancora diversi possibili attacchi !
• Per impedire a di ottenere un repository falso , assicurarmi di utilizzare HTTPS per i miei repository ed eseguire localmente un server di nomi di cache di convalida ( DNSSEC ) come suggerisce Joe Sniderman (l'unica misura disponibile contro lo spoofing DNS che ho visto finora)
• Ma se il repository stesso è compromesso, l'elenco completo degli attacchi (vedi risposta lunga) è ancora possibile! (Vedi la parte " Come proteggersi " di seguito, per suggerimenti su come cercare di prevenirli)

Risposta lunga

Ho trovato il seguente documento che fornisce molte informazioni sull'argomento: Sicurezza nella gestione dei pacchetti Ecco una breve lista di attacchi da esso. Si occupa principalmente di yum e apt però.

Possibili attacchi

• Slow Retrieval - DoS: An attacker slows repository communication so that package managers will “hang” and will not error out or contact other repositories to retrieve package updates
• Endless Data - DoS / Crash: A malicious repository (or MITM) returns an endless stream of data in response to any file request
• Replay Old Metadata - Outdated Package: An attacker provides old metadata that is correctly signed, leading to possible installation of known defective historic version
• Extraneous Dependency - Any Signed Package: An attacker changes the metadata for a package to indicate it depends on a package or packages of the attacker’s choice
• Depends on Everything - DoS / Crash: An attacker changes the metadata for a package to indicate it depends on everything
• Unsatisfiable Dependencies - DoS / Outdated Package: An attacker causes a package manager to ignore valid packages because forged meta-data indicates unsatisfiable dependencies
• Provides Everything - Any Signed Package: An attacker changes the metadata for a package to indicate it provides any dependency the user requests
• Use Revoked Keys - Arbitrary Package: An attacker uses a revoked key to get users to install packages
• Escalation of Privilege - Arbitrary Package: An attacker compromises a key trusted for signing a specific group of packages and then gets users to accept signed malicious versions of other packages

Vorrei aggiungere i seguenti attacchi che forniscono semplicemente un pacchetto software dannoso:

• Attacco collisione prefisso eletto - Qualsiasi pacchetto (! ) : un utente malintenzionato consegna un pacchetto dannoso che fornisce lo stesso firma come pacchetto originale (estremamente costoso da creare, altamente efficace; è già successo in precedenza, vedi Flame maleware o commenti alla risposta di K-Yo)

• Chiave sviluppatore rubato - Qualsiasi pacchetto : la chiave degli sviluppatori originali viene utilizzata per firmare un pacchetto dannoso. (Come ha detto SteveDL, questo potrebbe essere più facile da realizzare di un attacco di collisione, ha lo stesso risultato, ed è anche successo prima)

• Utente stupido - Qualsiasi pacchetto : in realtà non è un attacco, ma se per esempio si consente l'installazione di pacchetti non sospetti, nessuno degli attacchi sopra indicati è necessario . Un utente malintenzionato sarà in grado di installare praticamente qualsiasi cosa sul tuo sistema senza troppi sforzi.

Ci sono molti punti interessanti nell'articolo, che iniziano con metadati del pacchetto (solitamente) non firmati, attacchi contro il resolver di dipendenza, attacchi MITM quando non si usano connessioni SSL per repository (che potrebbe avere un risultato simile a una cache DNS avvelenata ), nonché descrizioni dettagliate dei possibili attacchi elencati sopra (capitolo 3.2).

Non riesco a esaminare tutte le parti del foglio, ma di seguito è riportato un elenco di suggerimenti per proteggere APT / YUM:

Come proteggersi

There are several simple actions that will mitigate the effectiveness of many of the attacks:

1. Validate repository communication. By checking that file sizes and data rates are reasonable, APT and YUM could limit the effectiveness of endless data and slow retrieval attacks.
2. Track signature times. APT (and YUM if it adds metadata signing) should refuse to accept older versions of signed data. This would limit the effectiveness of the replay old metadata attack.
3. Use HTTPS. HTTPS makes it more difficult for an attacker to launch any of the attacks because a man in the middle will have a harder time masquerading as the repository.
4. Guard mirrors. Delegating control of a mirror for a distribution should be treated with utmost caution. This will help to prevent most of the attacks because it will be harder for an attacker to obtain the ability to impersonate the repository.
5. Sign metadata and packages. Signing both metadata and packages makes it more difficult for an attacker to launch most types of attacks.
6. Check metadata is correct. Once APT or YUM has decided to install a package, it should download the package and verify its signature and that the metadata matches the metadata provided by the repository. This will help to prevent the depends on everything attack and extraneous depends attacks when the attacker cannot correctly sign the package.

These measures will increase the difficulty in launching many types of attacks. However, within the architectures of APT and YUM there is no way to fix key revocation, escalation of privilege, provides everything, and unsatisfiable dependencies attacks. This means that the security architectures of APT and YUM are fundamentally inadequate to address these issues.

Non esitare a modificare / migliorare questo post!

Per rispondere alla tua domanda, è possibile falsificare i server di aggiornamento DNS; quindi, il tuo gestore pacchetti non dovrebbe installare pacchetti non firmati, un utente malintenzionato potrebbe inviarti dati errati, ma non lo accetterei.

La maggior parte delle distribuzioni usa OpenPGP per firmare i loro aggiornamenti.

Fedora e Debian fanno per esempio.

Devi solo assicurarti che la tua opzione automatizzata convalidi gli aggiornamenti con le chiavi valide (che è il comportamento predefinito nella maggior parte dei casi, se non tutti).

Dipende davvero dal tuo modello di minaccia. Se stai ospitando alcuni documenti di classe Wikileaks, potrebbe essere una vera minaccia. Se si tratta solo di un server occasionale su Internet, ti consigliamo di aggiornarlo il più spesso possibile prima di preoccuparti di questo tipo di attacco.