Quali sono i rischi dovuti all'attacco del canale laterale "challenge ACK" [CVE-2016-5696]?

Question

Quali sono i rischi dovuti all'attacco del canale laterale "challenge ACK" [CVE-2016-5696]?

#1 da (3 voti)

0

Ho appena letto più dettagliatamente sul recente CVE-2016-5696 vulnerabilità nei kernel Linux (versione 3.6 e abov) al link e lì viene indicato tramite un attacco usando il " challange ACK "canale laterale, i dati possono essere malosamente inseriti in una connessione TCP (ad esempio una risposta / richiesta HTTP).

Non ho completamente capito perché ho sempre pensato che naturalmente i dati possano essere iniettati / modificati in una connessione HTTP, perché non è crittografato per cominciare.

Ho ragione nel presumere che la differenza qui è che questo bug permette a qualcuno di iniettare dati in una connessione TCP, pur non essendo un nodo di inoltro di quella connessione TCP (qualcosa che forse formule fuori percorso)?

Più semplicemente, è sbagliato dire che essenzialmente il CVE-2016-5696, costituisce un thread (iniezione dannosa) che comunque esisteva, dato che il computer di inoltro "in-path" aveva sempre la modifica per modificare il contenuto ( se non impedito dalla crittografia TLS / SSL)?

tcp cve

posta humanityANDpeace 21.08.2016 - 11:33

fonte

1 risposta

Leggi altre domande sui tag tcp cve

Lettura di avviso SSL3: avviso: chiudi notifica Differenza tra socks5 e socks4 proxy?

score 3 · Accepted Answer

the difference here is that this bug allows someone to inject data into a TCP connection, while not being a relaying node of that TCP connection (something they maybe phrasing off-path)?

Qualcuno in grado sia di annusare che di modificare / iniettare pacchetti è stato in grado di modificare prima le connessioni TCP (e quindi HTTP). L'attacco del canale laterale "challenge ACK" sostituisce il requisito dello sniffing diretto (cioè in-path) con un'ipotesi intelligente sul numero di sequenza e sulla porta utilizzata da una connessione TCP esistente e consente quindi a un utente malintenzionato fuori percorso di modificare il connessione.

L'attacker deve comunque essere in grado di iniettare i pacchetti appropriati, ad esempio, è necessario che lo spoofing dell'indirizzo IP di origine sia possibile. Se questo è possibile e per quali indirizzi IP dipende dall'ambiente dell'attaccante. Probabilmente è possibile falsificare un indirizzo IP locale nella maggior parte delle reti locali a bassa sicurezza, ovvero hotspot pubblici o reti aziendali. Ma anche in questi ARP lo spoofing potrebbe avere successo, il che consente gli attacchi in-path più potenti contro l'utente locale. Lo spoofing degli indirizzi IP non locali è invece più difficile. La mia ipotesi, in qualche modo istruita ma non attendibile, è che questo è probabilmente impossibile con la maggior parte degli account DSL / via cavo perché l'ISP filtrerà l'IP falsificato. Ma potrebbe essere più facile in più reti aperte presso società di hosting o università. E, naturalmente, chiunque abbia accesso ai router su Internet "aperta" è in grado di falsificare IP, come i provider di servizi Internet e probabilmente anche le agenzie governative.