Izvještaji o ranjivostima generisani umjetnom inteligencijom uzrokuju glavobolje Linusu Torvaldsu i kompaniji

Zajednica koja koristi Linux kernel doživljava trenutak detaljan pregled načina prijavljivanja i upravljanja ranjivostimaOvo je uglavnom zbog direktnog uticaja AI alata na reviziju koda. Široko rasprostranjeno usvajanje ovih sistema dramatično je povećalo broj sigurnosnih upozorenja, ali je također otkrilo ozbiljan problem dupliranja, šuma i dodatnog opterećenja za održavatelje.

Linus Torvalds, centralna figura u projektu, otišao je toliko daleko da ga je opisao (u Bilješke o izdanju Linuxa 7.1-rc4) privatnu sigurnosnu listu kernela kao „gotovo potpuno neupravljivo“ zbog lavine izvještaja podržanih umjetnom inteligencijomMnogi od ovih izvještaja bili su duplikati ili pogrešno klasifikovani. Kao odgovor na to, projekat je objavio novu dokumentaciju integrisanu u Linux 7.1 koja redefiniše šta predstavlja stvarnu sigurnosnu ranjivost i kako treba postupati sa izvještajima generisanim korištenjem AI modela.

Sigurnosna lista preopterećena dupliciranim izvještajima

U svojim nedavnim komunikacijama u vezi s razvojem Linuxa 7.1, Torvalds je upozorio da je mailing lista za ranjivosti postala usko grlo gdje se važna obavještenja miješaju s mnoštvom redundantnih izvještajaProblem nije samo u količini, već u tome što različiti ljudi, koristeći iste automatizirane alate, na kraju dostavljaju potpuno iste nalaze.

Kako je objasnio, programeri gube mnogo vremena prosljeđujući poruke onima koji bi ih zaista trebali primiti ili pojašnjavajući da je greška već ispravljena. ispravljeno prije nekoliko dana ili sedmica u granama kernelaOva situacija, koju neki upoređuju sa "poplavom" e-mailova, prisiljava resurse da se posvete razjašnjavanju duplikata umjesto fokusiranja na nove i ozbiljne ranjivosti.

Willy Tarreau, veteran u održavanju stabilnog kernela poznat po svom radu na HAProxyju, pružio je ilustrativne brojke: Prije samo nekoliko godina, privatna mailing lista je primala između dva i tri izvještaja sedmično.Dok se sada dnevno obrađuje između pet i deset izvještaja. Mnogi dolaze iz analiza potpomognutih vještačkom inteligencijom koje, iako ponekad ukazuju na stvarne probleme, stižu u nepraktičnim formatima i bez pružanja relevantnih dodatnih informacija.

Torvalds se ne buni protiv vještačke inteligencije, već protiv njene zloupotrebe.

Iako se možda čini drugačije, Torvalds je jasno stavio do znanja da Ne protivi se upotrebi umjetne inteligencije kao alata za razvoj i reviziju.On sam priznaje da koristi ovakve sisteme u svom radu, ali insistira na tome da se oni moraju koristiti odgovorno i razborito.

U svojim porukama zajednici, naglasio je da su alati umjetne inteligencije „odlični“ kada zaista pomažu, ali postaju problem kada generiraju „nepotrebna bol i beskorisni fiktivni rad“Drugim riječima, sama činjenica da automatizovani model ukazuje na moguću ranjivost ne opravdava preplavljivanje sigurnosnih kanala loše verifikovanim izvještajima ili izvještajima kojima nedostaje tehnički kontekst.

Torvalds insistira da svako ko koristi vještačku inteligenciju za pronalaženje grešaka ne bi trebao samo prosljeđivati ​​sirovi rezultat, već Pročitajte dokumentaciju kernela, shvatite model prijetnje i, kad god je to moguće, navedite zakrpu ili barem konkretno objašnjenje utjecaja.Cilj je da ljudi dodaju vrijednost automatiziranom radu, umjesto da djeluju samo kao posrednici između alata i mailing liste.

Nova pravila u Linuxu 7.1: šta je ranjivost, a šta nije

Kao odgovor na ovu situaciju, kernel projekat je u Linux 7.1 uključio precizniju dokumentaciju o Koje kvarove treba tretirati kao sigurnosne ranjivosti, a koje su jednostavno greške koje treba rješavati uobičajenim kanalimaTekst, koji je napisao Willy Tarreau, već je dio Git stabla kernela i dostupan je prije izlaska Linuxa 7.1-rc4.

Vodič počinje od jednostavne ideje: Većinu grešaka ne bi trebalo usmjeravati kroz privatnu sigurnosnu listuUmjesto toga, trebalo bi ih otvoreno rješavati na javnim mailing listama za razvoj. Javna diskusija o problemima privlači više recenzenata, pokriva više slučajeva upotrebe i općenito dovodi do kvalitetnijih rješenja.

U dokumentu se navodi da je Linux već imao jasno definiran model prijetnjeOvo sada služi kao primarna referentna tačka pri odlučivanju da li se ranjivost treba rješavati privatno. Sigurnosna ranjivost se definira kao ona koja omogućava napadaču da dobije mogućnosti koje pravilno konfigurisan produkcijski sistem ne bi trebao imati, koja se razumno može iskoristiti i koja predstavlja stvarnu prijetnju značajnom broju korisnika.

U praksi, oni koji otkriju probleme pozvani su da se zapitaju da li je greška To zaista prelazi granicu povjerenja u tipičnom okruženju.Ako je odgovor ne, preporučeni pristup je provjera javnih mailing lista (kao što su LKML i mailing liste specifične za podsistem), a ne ograničenog sigurnosnog kanala. Uprkos tome, vodič dozvoljava određeni stepen opreza: u slučaju sumnje, bolje je privatno pregledati sumnjivu prijavu nego dozvoliti da prava ranjivost promakne mrežom.

Još jedna ključna stvar u tekstu je da Slanje običnih grešaka na privatnu mailing listu ne ubrzava njihovo rješavanje.Naprotiv, to troši vrijeme trijaže koje je sigurnosnom timu potrebno za prioritizaciju zaista kritičnih kvarova. Preplavljivanje tog kanala manjim problemima u konačnici pogoršava ukupnu zaštitu sistema zasnovanih na Linuxu, uključujući servere, cloud infrastrukturu i industrijske uređaje.

Model prijetnje: razdvajanje privilegija i isključeni slučajevi

Nova dokumentacija ažurira i detaljno opisuje model prijetnji kernelu, koji navodi garancije čije se kršenje smatra sigurnosni problem koji zaslužuje prioritetnu pažnjuTo uključuje odvajanje korisničkog prostora i kernela, izolaciju memorije između procesa, ptrace ograničenja, izolaciju IPC i mrežnih mehanizama i zaštite povezane s osjetljivim mogućnostima kao što su CAP_SYS_ADMIN, CAP_NET_ADMIN ili CAP_SYS_PTRACE.

Posebna pažnja se posvećuje korisničkim imenskim prostorima, gdje postavke poput CONFIG_USER_NS omogućavaju neprivilegovanim korisnicima da kreiraju izolovana okruženja. Projekat očekuje da ti slučajevi ne mogu ugroziti globalni sistemtako da svako kršenje te izolacije dobija na sigurnosnom značaju.

Analiziraju se i interfejsi za otklanjanje grešaka kao što su /proc/kmsg, perf ili debugfs, imajući na umu da je pristup osjetljivim informacijama putem ovih mehanizama rizičan. Mora biti blokiran osim ako to administrator izričito ne odobri.U suprotnom, postoji rizik od curenja podataka koji bi se mogli iskoristiti za usavršavanje napada ili eskalaciju privilegija.

Uz ovu definiciju garancija, vodič jasno navodi koje vrste problema Ne bi ih trebalo automatski označavati kao ranjivostiOva kategorija uključuje greške u zastarjelim granama kernela, nesigurne opcije kompajliranja koje je odabrao administrator, netačne dozvole u sysctl-u ili datotečnim sistemima, funkcije rezervirane za otklanjanje grešaka (LOCKDEP, KASAN, FAULT_INJECTION) i eksperimentalni kod u područjima za pripremu.

Nedostaci koji zahtijevaju Prekomjerne privilegije, laboratorijski scenariji daleko od upotrebe u stvarnom svijetu, manipulisani hardver, neupravljiv broj pokušaja ili konfiguracije koje nijedan razuman administrator ne bi primijenio u produkciji. Slično tome, curenje podataka bez jasnog iskorištavanja i određeni problemi u slikama datotečnog sistema, koje obično rješavaju alati poput fsck-a, spadaju izvan osnovnog opsega sigurnosnog kanala.

Nalazi potpomognuti umjetnom inteligencijom: od privatnog do javnog

Jedna od najupečatljivijih promjena u ažuriranju je pristup greškama otkrivenim uz pomoć umjetne inteligencije. U dokumentaciji se navodi da Greške otkrivene putem automatizovane analize treba tretirati kao u suštini javnečak i ako se prva pošiljka izvrši privatnom poštom.

Razlog je čisto praktičan: nedavno iskustvo sigurnosnog tima pokazuje da se ovi propusti obično događaju. istovremeno u rukama nekoliko istraživača koji eksperimentišu sa sličnim alatima. Uobičajeno je da nekoliko e-poruka stigne u roku od nekoliko sati opisujući isto stanje, s malim varijacijama u formatu, što čini svako očekivanje produžene povjerljivosti nerealnim.

Ova nova stvarnost navodi Torvaldsa da tvrdi da Nema smisla tretirati ove nalaze kao tajne koje moraju biti skrivene dok se ne pojavi zakrpa.Ako ih obična umjetna inteligencija može pronaći, razumno je pretpostaviti da i drugi akteri, uključujući potencijalne napadače, mogu postići isti rezultat. Označavanje tih ranjivosti kao rezerviranih samo dodaje dodatni posao i komplicira koordinaciju.

To ne znači da se preporučuje objavljivanje svih tehničkih detalja bez filtriranja. Vodič traži da se, u slučajevima otkrivenim korištenjem umjetne inteligencije, Funkcionalni plejer za grešku nije odmah objavljen (tačan redoslijed koraka ili koda koji izaziva grešku). Odgovarajući pristup je naznačiti da ovaj materijal postoji i omogućiti održavateljima da ga privatno zatraže ako smatraju da je to potrebno za validaciju ispravke.

Ovim pristupom, projekat pokušava da spoji dva interesa: s jedne strane, Izbjegavajte zatrpavanje privatne liste nalazima za koje drugi već znaju.S druge strane, važno je ne nuditi bilo kome "recept" za iskorištavanje prije nego što se uspostave mjere ublažavanja. Media player je prepoznat kao vrijedan alat i za otklanjanje grešaka i za procjenu utjecaja, ali i kao osjetljivo pitanje ako se distribuira bez minimalnih kontrola.

Zahtjevi za kvalitet izvještaja generiranih umjetnom inteligencijom

Nova dokumentacija posvećuje cijeli odjeljak tome kako bi se trebali pisati izvještaji podržani umjetnom inteligencijom. Timovi za održavanje se često žale da mnogi od ovih izvještaja stižu pretjerano napuhan, sa suvišnim objašnjenjima i malo fokusa na bitne podatke, što otežava njegovo čitanje i klasifikaciju.

Prvo, traži se da izvještaji budu kratko, jasno i u jednostavnom tekstuTim ne preporučuje upotrebu formata poput Markdown-a, ukrasa ili složenih struktura koje ne podnose dobro lančane odgovore na mailing listama. Ideja je da se prilikom prosljeđivanja ili citiranja poruke ne gube nikakve informacije i tekst ne postaje nečitljiv blok.

Što se tiče sadržaja, preporučuje se da se počne sa Jednostavan sažetak koji ukazuje na pogođenu datoteku ili podsistem, pogođene verzije i vidljivi učinak greške.Odatle se mogu dodavati detalji, ali uvijek s namjerom da se olakša brzo čitanje koje vam omogućava da odlučite da li je kvar prioritetan ili spada u kategoriju manjih problema.

Još jedan važan aspekt je kako se opisuje utjecaj. Programeri kernela upozoravaju da mnogi izvještaji generirani umjetnom inteligencijom... Oni imaju tendenciju da preuveličavaju teorijske posljedice.povezivanje hipotetičkih scenarija koji ne poštuju stvarni model prijetnji projekta. Umjesto konstruiranja složenih narativa o napadu, od učesnika se traži da se drže provjerljivih činjenica, kao što je konkretno objašnjenje koje dodatne mogućnosti korisnik može dobiti na standardno konfiguriranom sistemu.

Vodič ide toliko daleko da sugerira da, gdje je to izvodljivo, sam AI alat treba prethodno pročitati dokumentaciju o modelu prijetnji za Linux. uskladiti svoje zaključke s kriterijima koje je projekt već utvrdioCilj je smanjiti nesporazume i spriječiti da automatsko prijavljivanje pretvori grešku s ograničenim utjecajem u navodnu kritičnu ranjivost bez ikakve stvarne osnove.

Igrači, zakrpe i zdrav razum u doba automatizacije

Pored načina opisivanja kvara, dokumentacija se fokusira na praktičnije aspekte: Generisanje i validacija igrača i zakrpa uz pomoć vještačke inteligencijeMnogi moderni alati mogu kreirati male testne programe ili skripte koji aktiviraju grešku, kao i predložiti promjene koda kako bi se ona ispravila, ali to ne čine uvijek pouzdano.

Jezgro insistira da, prije slanja izvještaja, Istraživač mora lično provjeriti da li plejer funkcioniše kako je opisano.Ako sekvenca ne izazove kvar ili ako vještačka inteligencija nije u stanju generirati ponovljivu metodu, validnost izvještaja je ozbiljno ugrožena. Objavljivanje nalaza bez ove verifikacije samo dodaje buku i troši vrijeme održavateljima.

Što se tiče zakrpa, tekst naglašava da su mnoge vještačke inteligencije još bolje. pisanje koda koji procjenjuje njegov utjecajStoga se korisnici ovih alata potiču da ih zamole ne samo da identifikuju problem već i da predlože rješenje. Međutim, naglašava se da rezultat mora biti ručno pregledan i testiran prije slanja na mailing liste za razvoj.

Vodič je nedvosmislen u slučajevima kada se flaster ne može testirati jer zavisi od egzotični hardver, praktično izumrli mrežni protokoli ili izuzetno rijetke konfiguracijeAko se greška manifestuje samo u tako marginalnom okruženju da je niko ne može lako validirati, vrlo je vjerovatno da nema relevantnu kategoriju sigurnosne ranjivosti i ne bi trebala trošiti vrijeme privatnog kanala.

Prilikom predlaganja ispravke, projekat podsjeća korisnike da se moraju pridržavati standardnih smjernica za slanje ispravki za kernel, uključujući oznaku „Ispravke:“ koje označavaju specifičnu commit datoteku koja je uvela greškuTakođer se predlaže primjena zdravog razuma: ako se pogođena datoteka nije mijenjala duže od godinu dana i održava je jedna osoba, moguće je da se radi o komponenti s vrlo malo stvarnih korisnika, kao što su stari hardverski upravljački programi ili zastarjeli datotečni sistemi.

U ovim slučajevima, preporuka je jasna: ako je problem trivijalan, lako ga je otkriti i nema očigledan utjecaj u tipičnim okruženjima, Najrazumniji pristup je da se to riješi direktno putem javnih građevinskih lista. a ne na listi posvećenoj sigurnosti. Na taj način, najosjetljiviji resursi su rezervirani za incidente s potencijalno ozbiljnim posljedicama.

Od ere fuzzinga do lavine umjetne inteligencije: lekcije za besplatni softver

Trenutna situacija donekle podsjeća na eru kada su počeli da se koriste alati za fuzzing poput Syzkallera. bombardirati kernel izvještajima o otkrivenim greškama na poluautomatski načinU to vrijeme, zajednica je morala naučiti kako integrirati taj kontinuirani tok otkrića u svoj razvojni proces, a da pritom ne uruši svoj svakodnevni rad.

Nešto slično se dešava sa vještačkom inteligencijom, ali na drugačijoj skali. Sada, ne samo da je generisanje ulaznih podataka koji uzrokuju greške automatizovano, već i... izrada samih izvještaja, statička analiza koda i predlaganje zakrpaOvo ubrzava pronalaženje grešaka, ali ako se greške ne filtriraju i ne prioritiziraju pravilno, to također umnožava broj e-poruka, paralelnih diskusija i očekivanja o tome šta kernel tim može podnijeti.

Unutar samog Linux ekosistema postoje nijanse u procjeni ovog fenomena. Greg Kroah-Hartman, još jedan ključni održavatelj kernela, istakao je da Izvještaji generirani umjetnom inteligencijom brzo su od gotovo uvijek gluposti postali valjani doprinosi.Ovaj optimističniji stav koegzistira s Torvaldsovom zabrinutošću zbog viška duplikata i preopterećenja sigurnosne liste.

Umjesto kontradikcije, ovi stavovi odražavaju dvije strane istog procesa usvajanjaS jedne strane, vještačka inteligencija može biti vrlo korisna za pronalaženje stvarnih problema; s druge strane, ako mnogi ljudi pokreću iste alate na istom kodu i šalju rezultate bez filtriranja, kombinovani efekat je "oluja" upozorenja kojom je teško upravljati.

Primjer odgovorne upotrebe automatizacije pruža sam Kroah-Hartman, koji je objavio prilagođene sisteme za skeniranje kernela, generiranje zakrpa, njihovo testiranje i slanje prema standardnom toku rada projekta. Ključno je da u tim slučajevima, Programer preuzima punu tehničku odgovornost za cijeli životni ciklus, umjesto jednostavnog prosljeđivanja bez provjere onoga što alat proizvodi.

Cijeli pokret oko Linuxa 7.1 pokazuje projekat koji, daleko od toga da odbacuje vještačku inteligenciju, jeste prilagođavajući svoje procese tako da automatizacija radi u korist sigurnosti, a ne protiv njePostavljanjem strožih kriterija za ono što predstavlja ranjivost, zahtijevanjem provjerljivih izvještaja u otvorenom tekstu i ohrabrivanjem umjetne inteligencije da doprinese generiranju i testiranju zakrpa, kernel ima za cilj zaštititi vrijeme održavatelja, smanjiti buku i usmjeriti napore na greške koje zapravo mogu ugroziti produkcijske sisteme.