Intervju z Bradom Spenglerjem (PaX Team/grsecurity)

• :: 1. jan 2010

English version

Brad "Spender" je nedvomno vrhunski varnostni raziskovalec na področju Linux jedra. Nenazadnje stoji tudi za razvpitimi "NULL pointer dereference" ranljivostmi, ki so pretresale Linux skupnost. Kot temeljni člen PaX/grsecurity projekta je za varnost Linux sistema naredil več, kot bi nekateri želeli priznati. Za mnoge je Brad kontroverzna osebnost, vendar mu kredibilnosti nihče ne oporeka.

Slo-Tech: Se lahko za začetek predstavite našim bralcem? Kakšni so vaši interesi, izobrazba in trenutna zaposlitev? Lahko razložite, ali je vaš resničen priimek Spengler ali Spender? In še to – ste bili kdaj član katere od black hat skupin?

Brad Spengler: Ime mi je Brad Spengler, ne Brad Spender, čeprav podobnost v imenih ni naključje. Vzdevek Spender je nastal kot variacija na moj resnični priimek. Na univerzi Bucknell sem diplomiral iz informatike in računalniškega inženiringa (nekakšna mešanica med bolj teoretičnim računalništvom in elektrotehniko oz. strojno opremo) z dodatno specializacijo na področju uporabne matematike. Med študijem so me najbolj pritegnili predmeti, povezani s matematiko, fiziko, ekonomijo in filozofijo, saj sem se z jedrom Linuxa ukvarjal že štiri leta pred prvimi predavanji o operacijskih sistemih, tako da me računalniške tematike niso najbolj pritegnile. V black hat skupinah pa nisem bil nikoli aktiven – že od osnovne šole naprej sem raje ustvarjal, kot uničeval.

Zabavna zgodbicam ki jo pogosto rad povem – v tretjem letniku smo dobili pri predmetu digitalnega oblikovanja za nalogo izdelavo interaktivnega vezja, ki je delovalo s pomočjo Xilinxovega programabilnega čipa. Ostali študentje so se lotili enostavnejših projektov, kot je igra križci-krožci, sam pa sem si želel večjega izziva (in Karnaughjevih diagramov, s katerimi bi se zabaval med računalniškimi predmeti), zato sem oblikoval lasten kriptoprocesor. Temeljil je na enkripciji DES, ki sem jo malce predelal, določil potrebne ukaze in ustvaril svoj zbirni jezik, zbirnik ter simulator. Model kriptoprocesorja sem nato prepisal v omenjeni zbirni jezik in ga prevedel ter shranil strojno kodo v dva ROM-a. Če se pravilno spominjam, je vse skupaj teklo na 12-bitnem RISC procesorju z registri in 256 bajti spomina. Izdelal sem načrt za aritmetično-logično enoto in jo ročno zoptimiziral s pomočjo Karnaugjevih diagramov. Končni načrti za vse komponente so obsegali okrog 100 strani, na vezju je bil zaslonček z 8 šestnajstiškimi znaki, katere je bilo možno upravljati z gumbi in stikali. Z dodatnim gumbom je lahko uporabnik kriptiral vhodne podatke in jih prikazal na zaslončku. Na žalost sem na koncu ugotovil, da svojega izdelka ne morem naložiti na Xilinxove plošče, s katerimi smo delali, saj je bil mnogo prevelik. Ker je bila uspešna demonstracija podlaga za 40% ocene, sem takoj pristal na šestici. najbrž bi bilo pametneje narediti križce-krožce ;).

Kar se tiče mojih interesov izven stroke, uživam v branju filozofskih del ali leposlovja s poudarkom na filozofiji. Kritično mišljenje je eno najpomembnejših znanj, če bi ga premoglo več ljudi, bi bil svet mogo lepši. Med drugim (slabo) igram bas kitaro, nedavno pa sem se se začel preizkušat tudi v ustvarjanju elektronske glasbe. Trenutno bi mi prav prišel nekdo, ki se s tem ukvarja že dlje in bi me lahko naučil določenih stvari.

Slo-Tech: Nam lahko na kratko opišete kaj sta PaX in GRSecurity in koliko ljudi sodeluje pri teh dveh projektih?

Brad Spengler: PaX je zver, ki je spremenila svet računalniške varnosti in ima v rokavu še nekaj asov, s katerimi bi znala v bližnji prihodnosti povzročiti še več sprememb. Osredotoča se na generično odstranjevanje ranljivosti na podlagi analize določenih tipov hroščev. Nekateri deli so še vedno nedokončani, ampak to se bo (upajmo) spremenilo in potem nas bodo čez kakšnih 8 let dohiteli tudi vsi ostali. PaX se povsem osredotoča na ranljivosti spomina, medtem ko GRSecurity doda še druge obrambne sisteme na strani gostitelja in pa omogoči dodatno podporo za določene funkcije PaX-a (upiranje napadom z grobo silo, preprečevanje uhajanja informacij in posledičnega zmanjševanja entropije pri ASLR-ju ter preprečevanje izvrševanja arbitrarne kode na nivoju datotečnega sistema), ki so potrebne za njegovo izboljšano delovanje. GRSecurity vsebuje mnogo avtomatskih funkcij tipa „nastavi in pozabi“ (na naši wiki strani je celoten seznam) in enostaven sistem RBAC (nadzor dostopa, ki temelji na uporabniških vlogah), ki poskuša poenostaviti ustvarjanje konfiguracije s pomočjo učenja (na proces, na uporabnika ali na sistem – vaša izbira), medtem ko istočasno preprečuje, da bi se administrator ustrelil v stopalo (ob zagonu se izvede mnogo varnostnih preverjanj za preprečevanje morebitnih slabih nastavitev, ki bi povsem izničile smisel tovrstnega nadzora dostopa). Konfiguracije so povsem berljive za ljudi, sporočila o napakah pa so uporabna, saj opisujejo napade, ki so vzrok za specifične varnostne nastavitve.

V PaX je vključeno neznano število ljudi! Torej ekipo definitivno sestavlja vsaj ena oseba. Na GRSecurityju trenutno delam samo jaz, občasno posamezniki prispevajo posamezne popravke (recimo Zbyniu Krzystolik). Prijatelji ali sponzorji včasih povedo, kakšno funkcijo bi želeli videti dodano, sicer pa programiranje in načrtovanje novih funkcionalnosti opravljam sam.

Slo-Tech: Le redki vedo, da je ekipa PaXa razvila nekatere varnostne mehanizme (kot recimo ASLR), ki so kasneje pristali v jedru Linuxa, kljub temu pa še vedno izgleda, da vas programerji in ostali vodilni, povzani z razvojem Linuxovega jedra, poskušajo diskreditirati. Kaj je po vašem mnenju mehanizem, ki v splošnem najbolj pripomore k varnosti Linux sistemov?

Brad Spengler: Zdi se mi rahlo smešno, da se je modri Ingo Molnar pred leti razburjal nad testnim orodjem paxtest, ki je preverjalo možnost izvajanja arbitrarne kode v različnih področjih naslovnega prostora pomnilnika, saj je vključevalo dodaten nabor preizkusov, ki so uporabljali mprotect za označevanje določenih delov za zapisljive in izvršljive. Po Ingovem mnenju je bil test „sabotiran“, saj naj bi bili preizkusi z mprotectom nekako nepošteni (ker exec-shield ni prestal niti enega). Potem previjemo čas nekaj let naprej in vidimo lahko, da je SELinux v bistvu dodal PaX-ovo funkcionalnost mprotect v svoj jezik za definiranje varnostnih pravil/politik (brez česar bi bil SELinux še bolj smešen in brez stika z realnostjo). V svetu Windows lahko lepo vidite, da praktično vsi izkoriščajo ravno ranljivosti kode, ki je ekvivalent tega, kar je mprotect v Linuxu. Glibc ima oz. je imel funkcijo make_stack_executable(), ki je najpogostejša tarča napadov ret2libc in tudi Windows ima nekaj podobnega. PaXovci smo že pred leti pričakovali, da se bodo napadalci začeli osredotočati na najšibkejši člen verige v sistemu in natanko to se dogaja sedaj.

Težko bi izbral specifično funkcijo, ki pripomore k varnosti Linux sistemov, saj se v veliki meri dopolnjujejo in nadgrajujejo. Razen tega bi rekel, da bodo najbolj revolucionarne ravno zadeve, ki jih bo naslednje predstavil PaX team.

Slo-Tech: Mnogi opažajo, da med vami in razvijalci jedra Linuxa poteka verbalen spopad. Kaj so glavni razlogi za to neprijetno situacijo? Se vam ne zdi, da v končni fazi izgubijo predvsem uporabniki?

Brad Spengler: Še nikoli nisem poslal e-maila razvijalcem Linuxa, tako da sam nikakor ne sprožam nobenih vojn. PaX team je tja že pisal (na primer takrat, ko smo želeli, da priznajo svojo javno politiko prikrivanja in obfuskacije varnostnih lukenj ter smešno ignoriranje določenih hroščev, za katere so si prislužili nagrado pwnie). Edini komentarji, ki jih pustim, so na LWN-ju (kot takrat, ko je Ingo širil laži o ranljivosti perf_counter) ali v komentarjih v kodi na vrhu ranljivosti, ki jih izdam v javnost, saj na to najpogosteje dobim odziv (oz. bolje rečeno – komercialne razvijalce skrbi negativno javno mnenje v medijih, zato se odzovejo in so prisiljeni izboljšati varnost). Za to, da se je odpravilo null pointer dereference hrošče, sem moral v javnost dati 8(!) ranljivosti. Sicer je res, da so takoj po prvi uvedli mmap_min_addr, ampak ker razvijalci jedra niso ravno varnostni strokovnjaki, tudi niso posebno dobri pri izdajanju varnostnih funkcij. Omenjeni mmap_min_addr je bil od izida za zaobit mnogo prevečkrat za tako majhno in enostavno funkcionalnost. Osnovni ASLR ima številne pomanjkljivosti. SSP (Stack-Smashing Protection) je bil večino časa, ko je bil v jedru, pokvarjen. Zdaj so še na silo omejili njegov obseg (Mislim, da kot odziv na moje odkritje, da je nepredvidljivo, kaj bo dejansko zaščitil – na Ingovem sistemu je SSP preprečil izkoriščanje hrošča perf_counter, na mojem sistemu pa je ni. Sploh ni sprožil sistemskega klica.) Vsi našteti varnostni sistemi so prišli iz istega komercialnega vira (Red Hat) – za podjetje, ki služi denar, je pomembno predvsem to, da lahko rečejo, da imajo funkcionalnost X (tako kot avtorji antivirusnih programov rečejo: „Varovali vas bomo pred virusi!“); ni pa pomembno, ali stvar dejansko deluje tako, kot bi morala (pa tudi preverjati se jim izgleda ne ljubi – to počno varnostni strokovnjaki in člani black hat skupin).

Slo-Tech: Katerega od razvijalcev jedra Linuxa zares spoštujete. Se vam ne zdi, da Linux potrebuje resno reorganizacijo na področju obvladovanja varnostnih incidentov razvoju varnostnih funkcij? Nekaj podobnega, kot Microsoftov SDL, morda. Kaj sploh mislite o SDL-u?

Brad Spengler: Močno spoštujem Microsoftov odnos do varnosti, posebno glede na to kako veliko podjetje so in na kako veliko populacijo vpliva njihova programska oprema. Če je v igri tako ogromen ekosistem programske opreme, kot je to v primeru Windowsa, se marsikaj spremeni. Mnogi prehitro spregledajo, kako zahtevno je razvijati varnostne funkcije in obenem ohranjati kompatibilnost z obstoječimi aplikacijami.

Linux nedvomno potrebuje bolj centralizirano vodstvo oz. organizacijo, ki bi skrbela za varnost. Razvijalci odpravljajo težave, za katere vedo, da so povezane z varnostjo, ampak o tem ne obveščajo upravljalcev distribucij in tistih, ki so s svojim delom podobno vezani na Linux. Nekateri sicer dobijo obvestila o določenih varnostnih težavah, a posebno manjši so pogosto izvzeti. Vsak od teh ljudi mora sam zase opravljati isto delo, kar je zelo neoptimalno, razvijalci pa skorajda delajo na tem, da otežujejo delo naslednjih v verigi. Uradna politika „vsak hrošč je samo hrošč“ škoduje vsem uporabnikom Linuxa. Nekatere stvari pa je vendarle treba pohvaliti – izboljšave določenih funkcij, ki so bile konstantni vektorji napadov (getsockopt, write(), copy_*_user), so zelo pripomogle k dodatni varnosti. Razvijalce prepogosto skrbi izguba hitrosti na račun varnosti; ampak nekaj procesorskih ciklov, ki so jih izgubili s preverjanjem negativnih dolžin pri klicu write(), jih je že neštetokrat rešilo iz dežav.

Slo-Tech: Ali mislite, da je Linus Torvalds dovolj sposoben za odločitve o varnosti? Sicer je res dober razvijalec, ni pa varnostni strokovnjak. Kaj pa ostali člani Linux Kernel Teama? Imajo dovolj znanja?

Brad Spengler: Ne, mislim da Linus na tem področju ni kompetenten; nima prave miselnosti in ne razume glavnih težav. Ne vem, če se povsem zaveda razlogov, zaradi katerih vsi ostali mislijo, da je varnost pomembna. Nekateri od razvijalcev sicer „štekajo“ varnost, ampak v glavnem se ukvarjajo predvsem s popravljanjem hroščev. V splošnem pa nikogar ne zanima utrjevanje sistema proti napadom in izboljševanje obnašanja v primerih, ko pride do napak.

Slo-Tech: Dave Aitel je na svojem poštnem seznamu napisal, da skupnost Linux potrebuje varnostni center, kjer bodo lahko vsi, so odvisni od jedra, prispevali in sodelovali pri reševanju varnostnih težav. Se strinjate? Bi bilo treba narediti korak v to smer in ali bi delali v takšnem centru?

Brad Spengler: Dave je imel popolnoma prav, ampak dvomim, da se bo to zgodilo. Najpomembnejša stvar, ki bi se morala spremeniti, je Linusov odnos do varnosti. On drži v rokah vse niti, tako da njegovo mnenje, naj bo pravilno ali napačno, oblikuje varnost v Linuxu. Ampak tudi to so bolj pobožne želje, zato bomo, dokler ne pride do sprememb, člani PaX teama še naprej delali, kar smo delali do sedaj; izboljševali varnost Linuxa na edini možen način – izven glavne veje razvoja.

Slo-Tech: Ali je res, da vzdrževalci jedra nekatere hrošče odpravijo na skrivaj? Ali to pomeni, da se jih posledično tudi napačno klasificira in označi kot manj?

Brad Spengler: Da, takšno prikrito popravljanje so že priznali. Če preberete moje pretekle komentarje na LWN, sem prispeval obilo primerov za to. Pa tudi pri hroščih, ki so bili povsem javno objavljeni in odpravljeni, je prihajalo do povsem napačnih klasifikacij – vsemu so rekli DoS. Odkar je na ta račun od različnih ljudi prišlo mnogo kritik, se je stanje malo izboljšalo. Del problema je spet pomanjkanje centralne organizacije, ki bi podala nedvoumno mnenje o resnosti hrošča – trenutno pogosto pride do tega, da ga različni ljudje različno analizirajo. Poleg tega nekatera podjetja sedaj komentirajo zadeve, ki niso varnostne težave (recimo na sistemih NOMMU – gre za namenske sisteme, na katerih ni varnostnih funkcij, uporabniške aplikacije lahko brez omejitev šarijo po pomnilniškem prostoru, namenjenem jedru, pa sta bila kljub temu izdana vsaj 2 CVE-ja, ki se dotikata izključno teh sistemov). Razlog za vse skupaj je dejstvo, da podjetja za delo na področju varnosti najemajo programerje namesto varnostnih strokovnjakov. No, to in pa ogromno število ranljivosti, s katerimi se morajo soočati, čeprav nimajo znanja in opreme, da bi jih korektno analizirali (pri čemer bi spet pomagala hipotetična centralna organizacija).

Slo-Tech: Sicer malce zlobno vprašanje, tako da vam ni treba odgovoriti, če nočete... Bi sprejeli službo pri Microsoftu, če bi vam jo ponudili (kot so jo Crispinu Cowanu, vodilnemu razvijalcu AppArmor ter StackGuard mehanizmov)? Pa pri Red Hatu?

Brad Spengler: Na razgovor pri Microsoftu sem v zadnjem letniku univerze že bil povabljen, ampak sem ponudbo zavrnil, saj so jo poslali kakšno leto po tem, ko je njihov kadrovski oddelek izgubil moje podatke (jaz pa zanimanje, za delo pri njih). Kar pa se tiče Red Hata – mislim, da lahko to kar sami ugotovite.

Slo-Tech: Dobro znano je, da za svoj primarni operacijski sistem uporabljate Windows Visto. To je precej čudno za enega najbolj uveljavljenih raziskovalcev Linux varnosti. Zakaj je prišlo do te odločitve in ali ste že odkrili kakšnega hrošča v Windows?

Brad Spengler: V bistvu sedaj uporabljam Windows 7 -- mislim, da je bil videoposnetek o ranljivosti Cheddar Bay narejen v verziji RC. Windows uporabljam zato, ker se želim z Linuxom ukvarjati samo za potrebe testiranja in izboljševanja GRSecurityja. V srednji šoli in na univerzi sem Linux sicer uporabljal kot primaren namizni sistem, dandanes pa želim samo čimbolj učinkovito opraviti delo – Linux tako ostaja v navideznem stroju. Poleg tega je bil včasih Linux mnogo enostavnejši, tako v jedru kot za končnega uporabnika. Imel si znane konfiguracijske datoteke in če si jih urejal, jih noben „inteligenten“ proces ni spreminjal za tvojim hrbtom, ni ti bilo treba spreminjati nastavitev SELinux, samo ker si hotel spremeniti naslov gostitelja z lokacije, različne privzeti. Prisoten je bil nekakšen občutek svobode – nekaj, kar se s komercializacijo izgublja. Še en razlog: igre. Igram jih. Nove. In če me Pidgin opomne, da je na voljo nova različica, enostavno prenesem samo novo izvršljivo datoteko, ni pa mi treba istočasno posodobiti več kot sto novih paketkov, kar zna marsikdaj pokvariti katero drugo funkcionalnost.

Slo-Tech: Zakaj podatke o ranljivostih objavljate javno, namesto da bi jih prodajali podjetjem, kot so iDefense, ZDI, Immunity... Kakšna je približna tržna vrednost lokalnih root ranljivosti, kot so cheddarbay, ingom0wnar in wunderbar?

Brad Spengler: Ne vem, če se omenjena podjetja ravno zanimajo za lokalne ranljivosti – kot prvo so vse od njih temeljile na hroščih, ki so bili vsaj v eni razvojni veji že odpravljeni. Kot drugo je bila koda za izkoriščanje teh ranljivosti vedno zelo preprosta. Posledično je bilo vse skupaj koristno predvsem za spreminjanje mnenja razvijalcev (in seveda je tudi delovalo; česar diskusija ni mogla spremeniti, je spremenilo 8 javnih exploitov). V končni fazi je tudi pripomoglo ljudem, da so se zavedli stopnje tveganja (veliko ljudi me je kontaktiralo in mi povedalo, da so končno lahko šefu pokazali, kako pomembna je varnost), ker pred tem že nekaj časa ni bilo javno objavljenih ranljivosti – pa ne zato, ker ne bi obstajale, ampak ker so jih black hat skupine hranile zase. Druga posledica je to, da imajo zdaj vse večje distribucije privzeto onemogočeno opcijo, ki omogoča napad null pointer dereference, ranljivost v SELinuxu je bila odpravljena in razvijalci so bolj pozorni na to, kdaj morajo res nujno izklopiti mmap_min_addr. Uporabniki se zdaj bolj zavedajo te funkcionalnosti in pomembnosti tega, da je vklopljena. Dosti ljudi se je tudi premaknilo z grozno starih verzij jeder. Vse našteto so zelo dobre stvari. Edina ranljivost, ki sem jo napisal, za katero bi lahko rekli, da je „inovativna“, je ogrodje Enlightenment, ki je predmet naslednjega vprašanja.

Slo-Tech: Nedavno ste izdali ogrodje za izkoriščanje hroščev v Linux jedru, imenovano Enlightenment. Ali načrtujete nadaljni razvoj in izboljšave, da bi lahko nekoč postalo podobno Metasploitu?

Brad Spengler: Ja, Enlightenment nenehno izboljšujem, saj me pripravi do tega, da razmišljam kot napadalec, kar mi nato pomaga pri razvijanju zaščit proti določenim napadom (s pomočjo teh metod sem pred kratkim v GRSecurity implementiral mnogo stvari). Prav tako bi želel narediti čimbolj zaključen izdelek - Enlightenment že podpira 32- in 64-bitna jedra, vsa jedra verzij 2.4 in 2.6 in onemogoči vse LSM module. Nedavno sem dodal še podporo za Xen, tako da bo lahko izvajal primerne hiperklice, kar bo omogočalo modifikacijo kode jedra. Razmišljal tudi o ločevanju imenskega prostora in vsebnika (beden prevod!), tako da imam to na TODO seznamu. Lahko pa povem, da bo Enlightenment ostal pri lokalnih ranljivostih Linux jedra.

Slo-Tech: Mnogi ljudje lokalnih ranljivosti ne jemljejo resno. Vem, da je Sebastian Krahmer (SuSE/Novell) napisal nekaj dobrih argumentov na ta račun in sam se popolnoma strinjam z njim, ampak resnica je, da trenutno ni v obtoku nobenih oddaljenih ranljivosti (če se pravilno spomnim, je zadnjo objavil Sgrakkyu). Je res nemogoče na daljavo vdreti v nemodificiran Linux sistem ali bi se znalo to v prihodnosti spremeniti?

Brad Spengler: Oddaljene ranljivosti je težko izkoristiti, še posebno, če se v jedro vključuje PaX in če je prevedeno po meri. Samo poglejte sgrakkyev in twizov prispevek v Phrack (Attacking the core: Kernel exploitation notes), pa boste videli, kako kompleksne so zadeve. Onadva sta pač nora na zahtevne naloge, ostali pa raje izberejo linijo najmanjšega odpora – to je danes izkoriščanje hrošča v spletni aplikaciji in nato zloraba lokalne ranljivosti. Z novimi funkcionalnostmi, predvidenih v PaX-u, bo eksploatacija postala zahtevnejša, ne enostavnejša. Še vedno pa bo po mojem mnenju omenjeni vektor napada ostal kar nekaj časa enak. Distribucije zapravljajo čas z nižanjem sistemskih privilegijev programske opreme, za katero ni prav verjetno, da bi imela resnejše varnostne luknje, medtem ko se po drugi strani vsak teden odkrije nova lokalna ranljivost jedra. Razvijalci spletnih aplikacij (ki pišejo kodo, prisotno na vsakem normalnem javnem strežniku in s tem spreminjajo oddaljene uporabnike v lokalne uporabnike z nizkimi privilegiji) pa prav tako ne postajajo nič pametnejši.

Slo-Tech: Lahko še vedno rečemo, da je Linux varen operacijski sistem? Bi ga priporočali vladnim organizacijam in vzdrževalcem podobno kritične infrastrukture?

Brad Spengler: Srčno upam, da se za kritično infrastrukturo uporablja kak varnejši OS, kar pa se tiče priporočil – moje mnenje je v splošnem še vedno to, da se da varen OS z neumnimi napakami narediti nevaren, tako kot je možno nevaren sistem narediti varen, s tem, da ga naredimo neuporabnega.

Slo-Tech: Imate na svojem trdem disku kako zasebno 0-day ranljivost?

Brad Spengler: Da, ext4_own.tgz, manjšo od kilobajta (nič več 0-day in zatorej javno objavljena).

Hvala Bradu Spenglerju za intervju.