Il Wi-Fi danneggiava i file ISO: per riparare il router TP-Link ha scritto un exploit kernel

Un access point Wi-Fi 7 che altera silenziosamente i dati durante il trasferimento, un produttore che interrompe gli aggiornamenti firmware e una vulnerabilità del kernel Linux sfruttata per ottenere i privilegi di root. Sono gli ingredienti di una vicenda tecnica piuttosto singolare, raccontata da uno sviluppatore che per correggere un problema del proprio TP-Link EAP770, ha dovuto sviluppare un exploit capace di aggirare le restrizioni imposte.

Il caso mette insieme tre questioni cruciali: l’affidabilità della trasmissione dei dati, i meccanismi di accelerazione hardware delle reti e il controllo effettivo che un proprietario può esercitare sui dispositivi acquistati.

Tutto è cominciato con alcuni download che fallivano senza una spiegazione apparente. La causa, individuata dopo un’indagine durata mesi, risiedeva nella gestione della memoria da parte di un driver Qualcomm.

Il router corrompeva i file senza segnalare errori di rete

Il dispositivo coinvolto appartiene alla prima generazione di apparati Wi-Fi 7, commercializzati quando le specifiche IEEE 802.11be non avevano ancora completato il percorso di standardizzazione. Nello specifico, il dispositivo EAP770(EU) acquistato ad agosto 2023 risulta basato sul SoC Qualcomm IPQ9574 e, lato software, usava il kernel Linux 5.4.164.

Le connessioni Wi-Fi funzionavano, la navigazione non presentava anomalie particolarmente evidenti e i trasferimenti brevi terminavano normalmente. Copiando file di alcuni gigabyte tramite rsync e SSH, però, comparivano errori di integrità che interrompevano le operazioni.

Inizialmente i sospetti si erano concentrati su rsync, sul client SSH e sulle impostazioni di trasferimento; modificando alcuni parametri, la frequenza dei problemi sembrava diminuire, senza tuttavia eliminarli.

Un indizio importante è arrivato dall’utilizzo di Tailscale, soluzione VPN che sfrutta WireGuard.

Quando i trasferimenti attraversavano il tunnel cifrato, gli errori praticamente scomparivano. Il motivo si sarebbe chiarito soltanto in seguito: WireGuard verifica l’autenticità e l’integrità dei pacchetti, scartando quelli che non superano il controllo crittografico. Il protocollo TCP trasportato nel tunnel cifrato può rilevare indirettamente la perdita e ritrasmettere i dati.

Perché TCP non rilevava la corruzione dei dati?

L’aspetto più sorprendente emerse durante l’analisi dei pacchetti con tcpdump. Lo sviluppatore individuò un segmento TCP di 1.440 byte contenente 64 byte consecutivi alterati. Eppure, il checksum TCP risultava perfettamente valido.

Il contatore Linux TcpInCsumErrors rimaneva a zero. Dal punto di vista dello stack TCP del client, quindi, il pacchetto non presentava alcuna anomalia e poteva raggiungere normalmente il livello applicativo.

Qui entravano in gioco TLS e SSH. Entrambi utilizzano controlli crittografici capaci di rilevare alterazioni dei dati trasportati, anche quando il checksum di rete non segnala problemi. Il risultato erano errori di autenticazione dei record TLS o dei messaggi SSH, apparentemente riconducibili alla cifratura.

Il punto è che il checksum TCP non garantisce l’integrità crittografica. Serve principalmente a individuare errori accidentali durante il trasporto e può essere ricalcolato da un dispositivo intermedio che modifica il contenuto del pacchetto. Se un apparato altera alcuni byte e successivamente aggiorna il checksum, il destinatario non ha modo di identificare la modifica attraverso il solo controllo TCP.

Per verificare l’ipotesi, il ricercatore abbandonò temporaneamente HTTPS e SSH, passando a trasferimenti TCP non cifrati tra un computer collegato tramite Ethernet e un portatile connesso via Wi-Fi. Conoscendo preventivamente i dati trasmessi, poteva confrontare ogni byte all’arrivo.

Il risultato fu decisivo: trasferendo 8.192 MiB, pari a 8 GiB, con più connessioni TCP contemporanee, il sistema rilevò tre blocchi corrotti da 64 byte. Le alterazioni comparivano soltanto nel percorso dalla rete cablata al client wireless.

I dispositivi collegati esclusivamente via Ethernet non manifestavano il problema. Inoltre, i controlli di integrità dei frame Wi-Fi risultavano corretti. Le prove indirizzavano quindi verso l’elaborazione interna dell’access point, anziché verso interferenze radio, errori del client o difetti del collegamento Ethernet.

La causa nascosta: un errore nella gestione della cache e del DMA

Un dispositivo come EAP770 utilizza meccanismi di accelerazione per sostenere velocità elevate: riducono il lavoro della CPU e abbreviano il percorso dei pacchetti.

Nel dispositivo esaminato intervengono componenti Qualcomm come Shortcut Forwarding Engine (SFE) e Packet Processing Engine (PPE); il driver qca-nss-dp gestisce invece aspetti del trasferimento dei pacchetti attraverso le interfacce Ethernet e i relativi buffer. L’analisi del codice sorgente del driver Qualcomm ha però portato alla luce una gestione problematica della coerenza tra cache della CPU e memoria DMA.

Il DMA, Direct Memory Access, consente a una periferica di leggere o scrivere direttamente nella memoria RAM senza coinvolgere la CPU nel trasferimento di ogni byte. È una tecnica fondamentale per ottenere prestazioni elevate nelle interfacce di rete.

Il problema risiede nella gestione della cache della CPU da parte del driver Qualcomm qca-nss-dp: per velocizzare il trasferimento dei pacchetti, il driver riutilizza alcuni buffer di memoria senza effettuare sempre tutte le operazioni necessarie a mantenerli coerenti con i dati trasferiti tramite DMA.

Durante la trasmissione, il driver pulisce soltanto una parte della cache, ma quando riutilizza lo stesso buffer per ricevere nuovi pacchetti presume erroneamente che l’intera area sia già pronta. Di conseguenza, vecchi dati ancora presenti nella cache possono sovrascrivere porzioni dei pacchetti appena ricevuti.

L’alterazione interessa blocchi di 64 byte, esattamente come quelli individuati dal ricercatore. A rendere il difetto particolarmente insidioso è il fatto che i pacchetti possono conservare un checksum TCP valido, perché il percorso di accelerazione può ricalcolarlo sui dati già corrotti; il problema emerge quindi soltanto quando protocolli come TLS e SSH verificano l’integrità delle informazioni ricevute.

Il firmware blocca la correzione: il ricercatore sfrutta una falla Linux per ottenere root

La soluzione al problema era relativamente semplice: impostare a 0 i parametri /sys/sfe/l2_feature e /sys/sfe/ppe_rfs_feature per disabilitare le accelerazioni di rete responsabili della corruzione dei dati.

Il firmware TP-Link, però, impediva di modificare tali impostazioni senza privilegi di root. Inoltre, il produttore aveva dichiarato l’End-of-Life ovvero la fine del supporto per il dispositivo EAP770 v1 già nel 2025, due anni dopo la commercializzazione, escludendo ulteriori aggiornamenti.

Il ricercatore ha quindi deciso di sfruttare CVE-2022-0185, una vulnerabilità del kernel Linux nota dal 2022 che, attraverso un errore nella gestione della memoria, permette in determinate condizioni di ottenere privilegi elevati.

Per adattare l’exploit al dispositivo ha utilizzato i sorgenti Linux di un modello TP-Link affine, un ambiente di emulazione QEMU e gli strumenti di analisi radare2, avvalendosi anche dell’assistenza dell’AI Claude Opus.

Dopo circa 17 ore di lavoro, il ricercatore è riuscito nell’intento di ottenere l’accesso root e modificare i due parametri, senza dover intervenire fisicamente sulla memoria flash dell’access point.

I risultati: zero blocchi corrotti e una perdita di velocità limitata

Dopo aver ottenuto i privilegi amministrativi, il ricercatore ha finalmente modificato i due parametri sysfs e ripetuto le misurazioni nelle medesime condizioni operative. Con l’accelerazione attiva, il trasferimento di 8 GB dalla rete cablata al client Wi-Fi raggiungeva 103,4 MB/s, ma produceva tre blocchi corrotti da 64 byte.

Disabilitando le funzionalità responsabili del problema, la velocità scendeva a 95,4 MB/s: durante test prolungati, però, non è comparso alcun blocco alterato.

La perdita di prestazioni misurata si colloca intorno all’8%; in cambio, i download di grandi dimensioni sono tornati a concludersi correttamente, senza dover ricorrere a trasferimenti suddivisi in parti o a continui tentativi di ripresa.

La correzione presentava tuttavia un limite importante: i parametri sysfs tornavano ai valori originali dopo ogni riavvio e, senza un aggiornamento firmware, non esisteva una modifica permanente facilmente applicabile. Così, per aggirare il problema, lo sviluppatore ha configurato un sistema di controllo sul proprio NAS: verifica lo stato dell’access point e, quando rileva il ripristino dell’accelerazione, riesegue l’exploit.

Qualche nota finale

Un apparato di rete può offrire prestazioni elevate, supportare standard wireless recenti e integrare diverse misure di protezione, ma diventare problematico quando il produttore interrompe troppo presto la manutenzione del software.

Nel caso raccontato, le restrizioni della shell impedivano persino di modificare due parametri del kernel per aggirare un difetto nella gestione dei pacchetti. Al tempo stesso, una vulnerabilità nota dal 2022 offriva un percorso alternativo per raggiungere proprio quei privilegi che il firmware negava all’amministratore.

È una contraddizione significativa: il dispositivo risultava sufficientemente protetto da ostacolare un intervento legittimo, ma non disponeva delle correzioni necessarie per eliminare tutte le vecchie vulnerabilità del sistema operativo.