Kees Cook chjama per una megliu urganizazione di travagliu in Linux in quantu à i bug fixes

Kees coce Facciu un post di blog in quale hà suscitatu inquietudine circa u prucessu di riparazione di bug in corsu in i rami stabile di u kernel Linux è hè cusì menziunate chì settimana à settimana circa un centu di currezzione sò incluse nantu à rami stabile, chì hè troppu è richiede assai sforzi per mantene i prudutti basati nantu à u kernel Linux.

Sicondu Kees, u prucessu di gestione di l'errore di u kernel hè bypassatu è à u kernel mancanu almenu 100 sviluppatori addiziunali per travaglià in modu coordinatu in questu spaziu. In più di menziunà chì i principali sviluppatori di kernel riparanu regolarmente bug, ma ùn ci hè nisuna garanzia chì queste riparazioni sianu purtate à varianti di kernel di terze parti.

In questu modu, ammenta chì l'utilizatori di parechji prudutti basati in kernel Linux ùn anu mancu modu di cuntrullà chì bug sò riparati è chì kernel hè adupratu nantu à i so dispositivi. In ultimamente, i vinditori sò rispunsevuli di a sicurità di i so prudutti, ma di pettu à un tassu assai altu di patch nantu à i rami stabile di u kernel, sò stati cunfruntati à a scelta di migrà tutti i patch, di migrazione selettiva di i più impurtanti, o ignurendu tutti i patch. .

I sviluppatori di u kernel upstream ponu risolve bug, ma ùn anu micca cuntrollu nantu à ciò chì un venditore downstream sceglie di incorporà in i so prudutti. L'utilizatori finali ponu sceglie i so prudutti, ma generalmente ùn anu micca cuntrollu annantu à chì bug sò riparati o chì kernel hè adupratu (un prublema in sè). In ultimamente, i venditori sò rispunsevuli di mantene i so nuclei di prudutti sicuri.

Kees coce suggerisce chì a soluzione ottima seria di trasferisce solu e riparazioni è vulnerabilità più impurtanti, ma u prublema principale hè di separà questi errori da u flussu generale, postu chì a maiò parte di i prublemi emergenti sò una cunsequenza di l'usu di a lingua C, chì richiede molta cura quandu si travaglia cù memoria è puntelli.

Per peghju, assai riparazioni di vulnerabilità putenziali ùn sò micca marcati cun identificatori CVE o ùn ricevenu micca un identificatore CVE qualchì tempu dopu a liberazione di u patch.

In tale ambiente, hè assai difficiule per i pruduttori di separà e correzioni minori da i prublemi maiò di sicurezza. Sicondu statistiche, più di u 40% di e vulnerabilità sò rimossi prima di l'assignazione CVE, è in media u ritardu trà una liberazione di riparazione è una assignazione CVE hè di trè mesi (vale à dì, à u principiu, una soluzione percepisce un sbagliu cumunu,

In cunziguenza, ùn avè micca un ramu separatu cù correzioni per e vulnerabilità è ùn riceve micca infurmazioni nantu à a cunnessione cù a sicurezza di questu o quellu prublema, i pruduttori di i prudutti basati nantu à u kernel Linux devenu trasfurmà continuamente tutte e correzioni di i novi rami stabile. Ma questu travagliu hè intensivu in manuvra è face a resistenza in l'imprese per paure di cambiamenti regressivi chì puderebbenu disturbà u funziunamentu normale di u pruduttu.

Chjave Cook crede chì l'unica soluzione per mantene u kernel sicuru à un costu ragiunevule à longu andà hè di trasferisce ingegneri di patch à e costruzioni di kernel pazziPer travaglià inseme in modu coordinatu per mantene e patch è vulnerabilità in u kernel upstream. In u so statu, assai venditori ùn usanu micca l'ultime versioni di kernel in i so prudutti è riparazioni di backport da soli, vale à dì chì l'ingegneri di diverse cumpagnie si giranu per duplicà u travagliu di l'altri, risolvendu u listessu prublema.

Per esempiu, se 10 cumpagnie, ciascuna cun un ingegneru chì sustene e stesse correzioni, redirige questi ingegneri per riparà bug in upstream, invece di migrà una soluzione, puderebbenu risolve 10 bug diversi per u benefiziu generale o riunite per rivedere i bug. . È evite micca include codice buggy in u kernel. E risorse puderanu ancu esse aduprate per creà novi strumenti di analisi di codice è di prova chì rilevanu automaticamente à un primu stadiu e classi tipichi di errore chì nascenu ripetutamente.

Chjave Cook prupone dinò di aduprà testi è fuzzing più attivamente automatizati direttamente in u prucessu di sviluppu di u kernel, aduprate sistemi di integrazione cuntinua è abbandunate a gestione arcaica di u sviluppu per mezu di e-mail.

source: https://security.googleblog.com


U cuntenutu di l'articulu aderisce à i nostri principii di etica edituriale. Per signalà un errore cliccate quì.

Sianu the first to comment

Lasciate u vostru cummentariu

U vostru indirizzu email ùn esse publicatu.

*

*

  1. Responsabile di i dati: Miguel Ángel Gatón
  2. Scopu di i dati: Cuntrolla SPAM, gestione di cumenti.
  3. Legitimazione: U vostru accunsentu
  4. Cumunicazione di i dati: I dati ùn seranu micca cumunicati à terzi, eccettu per obbligazione legale.
  5. Archiviazione di dati: Base di dati ospitata da Occentus Networks (UE)
  6. Diritti: In ogni mumentu pudete limità, recuperà è cancellà e vostre informazioni.