Kees Cook-ek Linux-en lan antolaketa hobea eskatzen du akatsak konpontzeko

Kees sukaldaria Blog batean argitaratzen dut zeinetan akatsak konpontzeko prozesuaren inguruko kezka sortu du Linux kerneleko adar egonkorretan jarraitzen du eta hori da aipatu astez aste ehun zuzenketa sartzen direla adar egonkorretan, gehiegi da eta Linux kernelean oinarritutako produktuak mantentzeko ahalegin handia eskatzen du.

Keesen arabera, kernelaren erroreak kudeatzeko prozesua saihestu egiten da eta nukleoak gutxienez 100 garatzaile osagarri ditu arlo honetan modu koordinatuan lan egiteko. Nukleoaren garatzaile nagusiek aldian-aldian akatsak konpontzen dituztela aipatzeaz gain, ez dago bermerik konponketa horiek hirugarrenen kernel aldaeretara eramango direnik.

Hori egitean, Linux kernelean oinarritutako hainbat produktuen erabiltzaileek ere ez dutela kontrolatzen modurik zein akats konpontzen diren eta zein gailutan erabiltzen den nukleoa kontrolatzeko. Azkenean, saltzaileak beren produktuen segurtasunaz arduratzen dira, baina kernel adar egonkorretan adabaki kopuru oso altuaren aurrean, adabaki guztiak migratzea, garrantzitsuenak modu selektiboan migratzea edo adabaki guztiak alde batera uztea aukeratu zuten. .

Upstream kernel garatzaileek akatsak konpon ditzakete, baina ez dute kontrolik downstream saltzaile batek bere produktuetan sartzea aukeratzen duenaren gainean. Azken erabiltzaileek beren produktuak aukeratu ditzakete, baina orokorrean ez dute kontrolatzen zein akats konpondu diren edo zein kernel erabiltzen den (arazoa berez). Azkenean, saltzaileek beren produktuen muinak seguru mantentzeaz arduratzen dira.

Kees sukaldaria Iradokitzen du irtenbide egokiena konponketa eta ahultasun garrantzitsuenak soilik transferitzea izango litzatekeela, baina arazo nagusia akats horiek fluxu orokorretik bereiztea da, sortzen ari diren arazo gehienak C lengoaiaren erabileraren ondorioa baitira, memoriarekin eta erakusleekin lan egitean arreta handia eskatzen baitu.

Hori gutxi balitz, balizko ahultasun konponketa asko ez daude CVE identifikatzaileekin etiketatuta edo ez dute CVE identifikatzailerik jasotzen adabakia askatu eta denbora gutxira.

Ingurune horretan, oso zaila da fabrikatzaileek konponketa txikiak segurtasun arazo nagusietatik bereiztea. Estatistiken arabera, ahultasunen% 40 baino gehiago kentzen dira CVE esleipena baino lehen, eta batez beste, konponketa bertsio baten eta CVE esleipenaren arteko atzerapena hiru hilabetekoa da (hau da, hasieran konponbidea akats arrunt gisa hautematen du ,

Ondorioz, ahultasunetarako konponketekin aparteko adar bat ez izatea eta arazo honen edo bestearen segurtasunarekin duen konexioaren inguruko informazioa ez jasotzea, Linux kernelean oinarritutako produktuen fabrikatzaileek konponbide guztiak etengabe transferitu behar dituzte adar egonkor berrien. Baina lan honek lan handia eskatzen du eta konpainien erresistentzia jasaten du produktuaren ohiko funtzionamendua eten dezaketen aldaketa erregresiboen beldur delako.

Keys Cook uste du epe luzera nukleoa segurtasunez kostu arrazoiz mantentzeko irtenbide bakarra adabaki ingeniariak lekuz aldatzea dela kernel eroaren eraikuntzetaral modu koordinatuan elkarrekin lan egitea adabaki eta ahultasunak upstream kernelean mantentzeko. Dagoen moduan, saltzaile askok ez dituzte kernel bertsio berrienak erabiltzen beren produktuetan eta backport konponketak beren kabuz, hau da, konpainia desberdinetako ingeniariek elkarren lana bikoiztu egiten dute eta arazo bera konpontzen dute.

Adibidez, 10 konpainiek, bakoitza konponketa berdinak dituzten ingeniari batekin, ingeniari horiek birbidaltzen badituzte akatsak konponbidean gora aldatzeko, konponketa bat migratu beharrean, 10 akats desberdin konpon ditzakete onura orokorrerako edo akatsak berrikusteko elkartuko lirateke. . Eta saihestu buggy kodea nukleoan sartzea. Baliabideak kodeen analisirako eta probarako tresna berriak sortzeko ere erabil litezke, behin eta berriz automatikoki detektatuko lituzketenak behin eta berriro sortzen diren akats klaseak.

Keys Cook probak eta fuzzing automatizatuago aktiboak erabiltzea ere proposatzen du zuzenean kernelaren garapen prozesuan, etengabeko integrazio sistemak erabili eta posta elektronikoaren bidez garapenaren kudeaketa arkaikoa alde batera utzi.

Fuente: https://security.googleblog.com


Artikuluaren edukia gure printzipioekin bat dator etika editoriala. Akats baten berri emateko egin klik hemen.

Idatzi lehenengo iruzkina

Utzi zure iruzkina

Zure helbide elektronikoa ez da argitaratuko. Beharrezko eremuak markatuta daude *

*

*

  1. Datuen arduraduna: Miguel Ángel Gatón
  2. Datuen xedea: SPAM kontrolatzea, iruzkinen kudeaketa.
  3. Legitimazioa: Zure baimena
  4. Datuen komunikazioa: datuak ez zaizkie hirugarrenei jakinaraziko legezko betebeharrez izan ezik.
  5. Datuak biltegiratzea: Occentus Networks-ek (EB) ostatatutako datu-basea
  6. Eskubideak: Edonoiz zure informazioa mugatu, berreskuratu eta ezabatu dezakezu.