Alfonso Maruccia

NetUSB, la falla che viene da lontano

I ricercatori individuano una pericolosa falla di sicurezza in un driver di Linux, un problema che sembra venire dagli anni '90 e che mette a rischio i proprietari di un gran numero di router basati sul kernel FOSS

Roma - Il nuovo rischio per la sicurezza informatica domestica si chiama NetUSB, vale a dire un driver integrato nel kernel Linux sviluppato dalla società taiwanese KCodes e pensato per fornire accessibilità ai dispositivi USB tramite una connessione alla rete domestica o tramite WiFi.

Il driver NetUSB è affetto da un bug di buffer overflow, dicono i ricercatori, un problema molto comune qualche decade addietro ma che ora rappresenta una rarità nel panorama delle falle di sicurezza: se il nome che client NetUSB invia al server ha un valore superiore ai 64-bit, il driver presente sul server va in buffer overflow con tutte le conseguenze del caso.

Un malintenzionato potrebbe sfruttare il baco per mandare in crash i router o, peggio ancora, per provare a eseguire codice malevolo da remoto. La porta TCP su cui NetUSB è in ascolto è la 20005, e purtroppo il problema coinvolge un buon numero di brand di ampia diffusione.
I ricercatori hanno analizzato molti firmware di dispositivi consumer, individuando il driver fallato nei router di D-Link, Netgear, TP-Link, Trendnet, ZyXEL e nel complesso in 92 diverse marche e milioni di macchine vulnerabili. A peggiorare la situazione c'è anche l'impossibilità, in buona parte dei casi, di disabilitare la funzionalità di NetUSB a livello di kernel.

Interpellati sul problema, i produttori delle succitate marche di router hanno comunicato pubblicamente la volontà di prendersi le dovute responsabilità ancora in pochi casi: ZyXEL e Netgear sono tra i brand che hanno riconosciuto l'esistenza della falla e hanno dichiarato di essere al lavoro su una patch correttiva. D-Link segnala che i modelli coinvolti sono DIR-615 e DIR-685, ormai poco diffusi in Italia: l'azienda ha ad ogni modo promesso di rilasciare un aggiornamento del firmware entro la prossima settimana.

Alfonso Maruccia
Notizie collegate
30 Commenti alla Notizia NetUSB, la falla che viene da lontano
Ordina
  • ... la storia del blob!
    non+autenticato
  • - Scritto da: BSD lover
    > ... la storia del blob!
    Si ma.... fammi capire c'è qualcuno che ti obbliga a usare i driver con i blob?
    non+autenticato
  • - Scritto da: 6 giaguar
    > - Scritto da: BSD lover
    > > ... la storia del blob!
    > Si ma.... fammi capire c'è qualcuno che ti
    > obbliga a usare i driver con i
    > blob?

    il fatto che altrimenti non potresti usare buona parte delle periferiche? (cit.)
    non+autenticato
  • - Scritto da: ...
    > - Scritto da: 6 giaguar
    > > - Scritto da: BSD lover
    > > > ... la storia del blob!
    > > Si ma.... fammi capire c'è qualcuno che ti
    > > obbliga a usare i driver con i
    > > blob?
    >
    > il fatto che altrimenti non potresti usare buona
    > parte delle periferiche?
    > (cit.)

    BSD manco coi blob parte...
    non+autenticato
  • - Scritto da: ...

    > il fatto che altrimenti non potresti usare buona
    > parte delle periferiche?
    > (cit.)
    Mi pare poco verosimile dato che la msacchina che sto usando non ne ha nessuno.
    A bocca aperta
    non+autenticato
  • - Scritto da: 6 giaguar
    > - Scritto da: ...
    >
    > > il fatto che altrimenti non potresti usare
    > buona
    > > parte delle periferiche?
    > > (cit.)
    > Mi pare poco verosimile dato che la msacchina che
    > sto usando non ne ha
    > nessuno.
    > A bocca aperta

    Certo che non ne ha , non funzionano ! A bocca aperta
  • il problema è che linux per essere compatibile con molti hardware integra nel kernel svariati blob nell'install di default, mentre i BSD al contrario se vuoi te li installi dopo e solo quelli che ti servono. Ecco cosa avevo detto...
    non+autenticato
  • - Scritto da: BSD lover
    > il problema è che linux per essere compatibile
    > con molti hardware integra nel kernel svariati
    > blob nell'install di default, mentre i BSD al
    > contrario se vuoi te li installi dopo

    Ah si??? E allora perchè lo deblobbano?

    > e solo
    > quelli che ti servono. Ecco cosa avevo
    > detto...

    Si predica bene e si razzola male...
    non+autenticato
  • abbè se ti vuoi tenere la scheda grafica NVIDIA che gira a 3 fps su Xorg fai pure, intanto nel BSD non te li mettono di default come su linuxCon la lingua fuori razzolone!!
    non+autenticato
  • - Scritto da: BSD lover
    > abbè se ti vuoi tenere la scheda grafica NVIDIA
    > che gira a 3 fps su Xorg fai pure, intanto nel
    > BSD non te li mettono di default come su linuxCon la lingua fuori
    > razzolone!!

    Menti spudoratamente:

    http://www.libertybsd.net/

    https://www.gnu.org/distros/common-distros.html#BS...

    Blob firmware di default in BSD, tutti i BSD, questa è la verità.

    Su linux te lo dicono in faccia di andarti a scaricare un kernel deblobbato, su bsd si nasconde l' esistenza dei blob di default e si spaccia il tutto per libero...
    non+autenticato
  • haha dai che poi si auto-rinomina '*nix lover' per par condicio!
    non+autenticato
  • serve una stringa di 64 caratteri, non di 64 bit!!

    “As part of the connection initiation, the client sends his computer name; the client can specify the length of the computer name. By specifying a name longer than 64 characters, the stack buffer overflows when the computer name is received from the socket. Easy as a pie, the ’90s are calling and want their vulns back, stack buffer overflow. All the server code runs in kernel mode, so this is a remote kernel stack buffer overflow.”


    ma noooo ... altro codice non controllato all'interno di un modulo del kernel Linux usato su solo qualche milione di router che permette ora di eseguire codice da remoto!!

    ma non c'e' piu' religione .......
    non+autenticato
  • - Scritto da: Linux & KCodes
    > serve una stringa di 64 caratteri, non di 64 bit!!
    >
    > “As part of the connection initiation, the client
    > sends his computer name; the client can specify
    > the length of the computer name. By specifying
    > a name longer than 64 characters
    , the stack
    > buffer overflows when the computer name is
    > received from the socket. Easy as a pie, the ’90s
    > are calling and want their vulns back, stack
    > buffer overflow. All the server code runs in
    > kernel mode, so this is a remote kernel stack
    > buffer
    > overflow.”
    >
    >
    > ma noooo ... altro codice non controllato
    > all'interno di un modulo del kernel Linux usato
    > su solo qualche milione di router che permette
    > ora di eseguire codice da remoto!!
    >
    >
    > ma non c'e' piu' religione .......
    ce ne sarebbe di piu, se l'lkm fosse open source e inserito nel kernel tree... invece infilare roba closed piace MOLTO agli oem (broadcom in testa) ...magari anche violando la GPL..
    non+autenticato
  • comprendo la voglia di trollare su linux, però informarsi prima no!?!

    il modulo in questione è closed-source e non fa parte del kernel tree di linux

    dunque qui il problema non è l'opensource, anzi questo caso dimostra che il closed sta messo pure peggio dell'open

    l'unica cosa che si potrebbe dire è che Tanenbaum aveva ragione su tutta la linea, ovvero i kernel monolitici/ibridi non sono adatti alle moderne necessità di computing

    e vale pure per os x e windows ( ma pure haiku, i bsd e altri OS alternativi )
    non+autenticato
  • se è per questo, anche Stallman col suo GNU Mach aveva e continua ad avere ragione Sorride

    l'unico a non averlo finora compreso è quel sempaticone di Linus

    bisognerebbe, a questo punto, giungere a comprendere soprattutto il perché una marea di intellettuali informatici siano andati appresso al pifferaio, anziché ragionare con la propria testa e dare ascolto ai veri illuminati
    non+autenticato
  • - Scritto da: GNU
    > se è per questo, anche Stallman col suo GNU Mach
    > aveva e continua ad avere ragione

    beh si e no e per due motivi

    1. Mach è dimostrabilmente il peggior microkernel ( alcuni si spingono fino ad affermare che non è nemmeno un microkernel ) mai concepito

    2. GNU Mach in particolare, sembra non avere una chiara direzione ( come del resto il resto dell'OS che c'è intorno e cioè Hurd )

    si sono proposti di fare delle cose, poi hanno man mano puntato sempre più in là e, dopo 25 anni, si ritrovano a zero

    > l'unico a non averlo finora compreso è quel
    > sempaticone di Linus

    non può, altrimenti dovrebbe dire "riscriviamo Linux"

    facile a dirsi, impossibile a farsi

    > bisognerebbe, a questo punto, giungere a
    > comprendere soprattutto il perché una marea di
    > intellettuali informatici siano andati appresso
    > al pifferaio, anziché ragionare con la propria
    > testa e dare ascolto ai veri
    > illuminati

    perchè? perchè all'epoca non c'era niente di meglio

    i bsd erano ( e sono ) fatti allo stesso modo

    darwin è un'accozzaglia di pezzi copyleft, con un microkernel sotto e uno stack monolitico sopra

    haiku ha seguito la strada "ibrida" ( così definiscono i monolitici quelli che si vergognano di usare il termine "monolitico" )

    qnx poteva essere l'uovo di Colombo, ma è stato reso poco opensource e poi comprato da Blackberry....vabbè....

    genode è l'unico a trovarsi nella posizione di poter cambiare le carte in tavola, ma ci sono troppi interessi in ballo nell'ecosistema linux, interessi che dovrebbe cambiare strada e per cosa?
    non+autenticato
  • ma chr dici?? nel BSD non c'è dentro il BLOB!!! l'unica schifezza l'ha fatta linux che fà girare mille periferiche con un unico mega kernel, metà closed source... bah!Sorride
    non+autenticato
  • - Scritto da: BSD lover
    > ma chr dici?? nel BSD non c'è dentro il BLOB!!!
    > l'unica schifezza l'ha fatta linux che fà girare
    > mille periferiche con un unico mega kernel, metà
    > closed source... bah!
    >Sorride
    certo che anche senza maxsix & co, nel giro di 2 post si deraglia subito dal thread e ci si infila in supercazzole che poco c'entrano....
    MA volendo polemizzare, e' proprio bsd il maggior aiuto al blobbing nei soho device... visto che broadcom e cugini pigliano la pappa pronta bsd e la ficcano in un unico megablob senza sorci (cosa che non possono fare con busybox, il kernel e altri affini)
    non+autenticato
  • e a parte questo chi ti obbliga a usare i drivers con i blob?
    non+autenticato
  • - Scritto da: 6 giaguar
    > e a parte questo chi ti obbliga a usare i drivers
    > con i
    > blob?

    il fatto che altrimenti non potresti usare buona parte delle periferiche?
    non+autenticato
  • - Scritto da: collione
    > - Scritto da: 6 giaguar
    > > e a parte questo chi ti obbliga a usare i
    > drivers
    > > con i
    > > blob?
    >
    > il fatto che altrimenti non potresti usare buona
    > parte delle
    > periferiche?
    e in quel caso (aime' come tutti sappiamo ben reale), per far pulizia, servirebbe ancora MENO filosofia bsd-like e meno torvalds, ma uno stallman con l'accettaCon la lingua fuori

    lo pesco da en.wiki ..
    In the opinion of Linux maintainers, LKM are derived works of the kernel. The Linux maintainers tolerate the distribution of proprietary modules,[citation needed] but allow symbols to be marked as only available to GNU General Public License (GPL) modules.

    Loading a proprietary or non-GPL-compatible LKM will set a 'taint' flag[4] in the running kernel—meaning that any problems or bugs experienced will be less likely to be investigated by the maintainers.[5][6]
    non+autenticato
  • ahahah ma sei sbroccato?? questo vuol dire che se crasha il sistema per un BLOB i linux ti girano le spalle, eh però di default ce ne sono dentro tanti!!! bella politica..
    non+autenticato