Michal Zalewski:
Przede wszystkim nie wydaje mi sie, abym wiódl zycie pod osloną mroku ani by moje dokonania sklanialy do popadania w przesadny mistycyzm. Jestem przypadkiem zapalonego, acz znającego umiar komputerowca. Od ponad siedmiu lat zajmuje sie zagadnieniami związanymi z programowaniem, administrowaniem i bezpieczenstwem systemów komputerowych. Pracowalem w kilku firmach w paru krajach, a obecnie pracuje w Polskiej Telefonii Cyfrowej, gdzie nasza grupa odpowiada za bezpieczenstwo systemów teleinformatycznych firmy.
Wlaściwie od zawsze zajmowalem sie i zajmuje tylko jednym – odkrywaniem tajników komputerów. Swoją przygode zacząlem dośc nietypowo – od nauki programowania i zrozumienia, jak dzialają wszystkie elementy komputera: od ukladu bramek i pamieci flip-flop po budowe procesora.
Gdy mialem mniej wiecej sześc lat, pojawily sie komputery ośmiobitowe. Początkowo nie mialem ani magnetofonu do wgrywania programów, ani kaset z grami. Cieszylem sie za to grubym przewodnikiem po tajnikach BASIC-a i asemblera Z80.
Z natury jestem dośc ostrozny i nieufny – po prostu nie bawiloby mnie obcowanie z urządzeniem, którego nie rozumiem i którego nie bylbym w stanie sam zbudowac. Mialem wiec motywacje, by wgryLc sie w temat. Ta gleboka fascynacja pozwolila mi po pewnym czasie zacząc kariere zawodową powiązaną z komputerami.
Od ponad siedmiu lat zajmuje sie zagadnieniami związanymi z programowaniem, administrowaniem i bezpieczenstwem systemów komputerowych, a mam 22 lata, wiec jest to pewne osiągniecie. Pracowalem juz w kilku firmach, i malych, i dośc znanych. Wszedzie dobrze wykonywana praca sprowadza sie do dwóch rzeczy: zrozumienia maszyny i zrozumienia ludzi, którzy sie nią poslugują.
Czasem podejmuje sie prób zrozumienia logiki rządzącej pewnymi procesami w komputerze lepiej, niz rozumieli ją autorzy oprogramowania czy algorytmów. Czesto mi sie to udaje, o czym świadczy zapewne moja obecnośc na listach typu BUGTRAQ, natomiast wbrew obiegowym opiniom nie robie tego dla slawy, pieniedzy czy pieknych kobiet. Owszem, bycie znaną osobą daje spore i zauwazalne korzyści, ale tez przysparza wielu wrogów. Prawdziwą satysfakcje daje mi samo przechytrzenie systemu. Dlatego staram sie nie publikowac informacji o blahych i nieciekawych problemach. Bardziej interesują mnie sytuacje, które wnoszą coś nowego związanego z bezpiecznym programowaniem… Bo kiedy nie zajmuje sie znajdowaniem dziur w cudzym kodzie, sam gram role programisty;-)
O Open Source
MJB: Jak oceniasz jakośc i bezpieczenstwo oprogramowania Open Source?
MZ:
Chociaz obiegowe opinie mówią o przewadze bezpieczenstwa kodu otwartego nad zamknietym, unikam tak radykalnych opinii. Kluczowym argumentem zwolenników Open Source jest to, ze kod moze byc i jest oceniany i poprawiany przez tysiące uzytkowników – praktyka dowodzi jednak, ze nie zawsze dochodzi do tego w zadowalającym stopniu. Stan oprogramowania Open Source jest bardzo niejednorodny. Sklanialbym sie tylko ku tezie, ze wiele popularnych projektów Open Source szybko osiąga znaczną poprawe jakości kodu, co nie jest czeste w świecie closed source, gdzie jakośc kodu pozostaje stala przez dlugi czas – natomiast w obu przypadkach wiele wciąz zalezy od tego, jakiej jakości byl kod początkowy.
Tylko popularne programy i ich czesto uzywane cześci mają za sobą stosowny poziom testów. Poniewaz w środowisku Open Source panuje zasada publikowania mozliwie wcześnie i czesto, nie istnieje zaden formalny mechanizm QA (pytan i odpowiedzi – przyp. red.) dla tych cześci kodu, które nie są uzywane zbyt czesto i których jakośc potrafi byc fatalna nawet wiele miesiecy póLniej, gdy wchodzą one do wersji stabilnych. W efekcie niektóre komponenty systemu pracują jak w zegarku – na przyklad fragmenty jądra systemu Linux – a te zaś, do których nikt nie zagląda, straszą swoim stanem.
Zeby nie byc goloslownym, posluze sie przykladem mechanizmu ptrace() we wspomnianym jądrze Linuksa. Mechanizm ten oferuje niezbyt moim zdaniem przemyślany i wydajny interfejs do śledzenia wykonywanych aplikacji i jest on uzywany raczej sporadycznie. Na kilka specyficznych sposobów wykorzystują go popularne debuggery, ale jest to raczej podejście dosyc powierzchowne.
Od wielu lat kod ten nie byl wlaściwie ruszany, jezeli nie liczyc latek na pojawiające sie exploity – a znajdzie sie tego calkiem sporo. Pozornie prosty mechanizm byl przyczyną calego multum lokalnych ataków, od DoS po zdobycie uprawnien administratora, a takie ataki, choc trudno w to uwierzyc, wciąz pojawiają sie co kilka miesiecy.
MJB: Czy zgodzisz sie z tezą, ze dostepnośc kodu Lródlowego obniza bezpieczenstwo oprogramowania i ze zamkniete oprogramowanie bywa bezpieczniejsze?
MZ:
Krótkofalowo – owszem. Czesto bywa tak, poniewaz trudniej dostrzec uchybienia lub rozpracowac logike dzialania skomplikowanych produktów, które dzialają na zasadzie czarnej skrzynki. Dlugofalowo – zwykle nie, poniewaz “trudniej” nie znaczy, ze coś jest niemozliwe. Poza tym z kazdej firmy odchodzą pracownicy i predzej czy póLniej wyciekają tez informacje… Z czasem rośnie tez prawdopodobienstwo zauwazenia czegoś niepokojącego przez czysty przypadek. W takiej sytuacji, jezeli jakiekolwiek elementy bezpieczenstwa produktu byly ukrywane, caly model legnie w gruzach.
Nie wydaje mi sie jednak, by byl to nagminny problem w świecie closed source. Chocby z tego powodu, ze znalezienie “dziur” jest wciąz mozliwe. W przypadku wielu zlozonych systemów istniejących na rynku od lat – na przyklad Microsoft Windows, Cisco IOS itp. wydaje mi sie, ze argument o wyzszym bezpieczenstwie zamknietych Lródel jest raczej posunieciem usprawiedliwiającym dany model biznesowy w oczach klientów. Z drugiej strony znaczyloby to, ze argument zwolenników Open Source, mówiący o tym, ze closed source moze byc niebezpieczny, bo nie podlega ocenie, jest czesto zdecydowanie przesadzony. Reasumując: ani Open Source nie jest poddawany pelnej analizie, ani tez closed source nie moze sie jej oprzec zbyt dlugo w skuteczny sposób.
