Lokální útoky na operační systém linuxového typu (diskuse)

[wake]

Cyklus 'if'???

[Luboš Doležel (Doli)]

Díky, opraveno.

[xxx]

spolu s goto, by if mohlo tvorit cyklus

[wake]

spolu s while i print muze tvorit cyklus...

[michich]

Není libsafe dnes již překonán standardními gcc/glibc vylepšeními FORTIFY_SOURCE a -fstack-protector? Fedora je s těmito volbami kompilována.

[bluemoon]

velmi pekny clanek...

[zelial]

dobrý článek! v závěru byly zmíněny další typy chyb - bude pokračování?

[Grunt]

Nemohu si pomoct, ale jaký je rozdíl mezi tímto článkem a str. 18-93 z knihy Hacking bez tajemstvý:Umění exploitace?

[m_ax]

Rozdiel je asi 70 stran :))

[kain]

tiez ma to napadlo. Pri fenceposte som si ihned spomenul hacking bez tajemstvi a domnienka sa potvrdila pri popise chyby openssh. Ale ten priklad je vynikajuci, tak preco ho nepouzit.

[Harvie]

V podpisu autora ;D

[marek]

supr článek děkuji

[michich]

Pro zájemce o tuto problematiku můžu doporučit prakticky zaměřený článek Ulricha Dreppera Defensive Programming (a prezentaci k němu). Zajímavý je taky Security Enhancements in RHEL (+ prezentace).

[Michal Kubeček]

Co máte pořád všichni s tím /etc/passwd, to všichni pořád dokola opisují z nějaké 15 let staré knihy nebo je to nějaká epidemie? Zkusil si autor opravdu na nějaké (aspoň trochu) současné distribuci přidat do /etc/passwd řádek, který uvádí, a poté se přihlásit jako uživatel r00t bez hesla? A fungovalo mu to?

[satanatas]

no vy ste tomu teda dal. teď už nic nebrání tomu, aby kdejaký bfu opsalo pár řádek do pc a dokázalo tak bez problému hackovat cokoliv. :*}

[pele]

Zkusil, funguje:)

[Michal Kubeček]

A to byla nějaká normální distribuce nebo jste nejdřív provedl řadu opatření, aby to mělo šanci fungovat?

[Mortal]

normalni gentoo bez zadnych specialnich uprav

[pele]

+1 sarge

[Michal Kubeček]

Tak to by mne docela zajímalo, kde udělali soudruzi z Gentoo chybu. Když tu položku, kde kdysi dávno býval hash hesla, nenecháte prázdnou, ale zkopírujete tam hash nějakého známého hesla, půjde se s tímto heslem přihlásit jako r00t? Používá ta distribuce standardní pam_unix.so nebo nějakou specialitu?

[Honza Jaroš]

Je tam pam_unix.so, /etc/pam.d/system-auth vypadá takto:

#%PAM-1.0

auth       required     pam_env.so
auth       sufficient   pam_unix.so try_first_pass likeauth nullok
auth       required     pam_deny.so

account    required     pam_unix.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow
password   required     pam_deny.so

session    required     pam_limits.so
session    required     pam_unix.so

Standardní rootovský záznam v /etc/passwd je potom takovýto: root:x:0:0:root:/root:/bin/bash

V každém případě - není to jedno? Pokud by někdo zvládnul zapsat do /etc/passwd, zvládne i zápis do /etc/shadow, ne?

[michich]

V každém případě - není to jedno? Pokud by někdo zvládnul zapsat do /etc/passwd, zvládne i zápis do /etc/shadow, ne?

Tak to vůbec není tak jisté. Třeba proto, že shadow má svůj SELinux kontext.

[Honza Jaroš]

V tom případě nechť někdo vyzkouší, jestli to funguje i v rámci SELinuxu. Protože pochybuju, že by ho někdo z nás, kdo to zkoušel, měl zapnutý.

V každém případě to, soudě podle příspěvku peleho, dělá i Debian, takže asi půjde o obecnější záležitost.

[azurIt]

Sarge nemam nikde ale v Etch to urcite nejde (skusal som len prazdne heslo). Slackware 10.2 ide.

[Honza Jaroš]

Pro zajímavost jsem teď zkusil pod VMware nainstalovat čistý aktuální Arch Linux a přihlášení funguje jak s prázdným heslem, tak s kopií hashe z jiného účtu...

[Honza Jaroš]

Abych nezapomněl - zkopírovaný hash hesla funguje.

[Grunt]

Co máte pořád všichni s tím /etc/passwd, to všichni pořád dokola opisují z nějaké 15 let staré knihy nebo je to nějaká epidemie?

Co je na /etc/passwd, špatného nebo snad 15 let starého?

Zkusil si autor opravdu na nějaké (aspoň trochu) současné distribuci přidat do /etc/passwd řádek, který uvádí, a poté se přihlásit jako uživatel r00t bez hesla? A fungovalo mu to?

A proč by to nemělo fungovat? Dokonce znam distribuci ve které byla hesla uvedena v tomto souboru.

[Michal Kubeček]

Trik je v tom, že na aspoň trochu rozumně nastavené distribuci to nemá nejmenší šanci fungovat. Už neexistence odpovídajícího řádku v /etc/shadow by měla být pro pam_unix.so dostatečným důvodem, aby přihlášení zamítl. Rozhodně by neměl umožnit přihlášení bez hesla na základě toho, co je (nebo není) ve druhé položce v /etc/passwd. A to nemluvím o tom, že mnohé distribuce vám přihlášení bez hesla neumožní ani v případě, že bude prázdná druhá položka v /etc/shadow. Pokud na nějaké distribuce uvedená finta projde v té podobě, v jaké je popsaná v článku, je to podle mne zralé na bugreport.

[pavlix]

Coz nic nemeni na moznosti zmenit /etc/shadow.

[Michal Kubeček]

A přesně o tom tu od začátku mluvím. Proč autor nenapíše "lze změnit obsah libovolného souboru" (to mi zní dostatečně hrozivě) nebo proč to nedemonstruje na /etc/shadow? Nebo proč, když už si vybere /etc/passwd, raději nepoužije jako ukázku něco, co by opravdu fungovalo? Protože to buď všichni opisují už patnáct let jeden od druhého nebo jsou posedlí tím tajemně zavádějícím názvem. Těžko říct, co je horší.

[Honza Jaroš]

Protože to minimálně v několika distribucích (zkoušel jsem Gentoo a Arch, podle příspěvku výše se to týká i Debianu Sarge) funguje i dnes?

[Michal Kubeček]

A nebylo by lepší použít jako ukázku něco, co funguje nejen v distribucích, kde někdo něco zanedbal?

[Honza Jaroš]

O tom se hádat nechci. Jen jsem chtěl říct, že pokud to autor zkoušel a fungovalo mu to, těžko mu můžeme vyčítat, že ho nenapadlo, že by to mohlo být v jiných distribucích jinak.

[Matyáš Dvořák]

Nejlip popsane preteceni zasobniku co jsem kdy cetl :)

[rastos]

Tým, ktorých problematika článku zaujíma odporúčam do pozornosti túto diplomovku.

P.S. Je škoda, že sa jednému trollovi podarilo vyprovokovať 80% príspevkov v tejto diskusii.

[rastos]

Sákriš. Ešte raz (pozor, je to .pdf).

[DNA]

Kontrola programátora také zvyšuje náchylnost na přetečení paměti. - mě ta věta nedává smysl, možná místo zvyšuje ovlivňuje

[Luboš Doležel (Doli)]

Tento jev je nazýván přetečení zásobníku (stack-based overflow).

Není to spíš přetečení bufferu na zásobníku? Pod přetečením zásobníku si představím Stack overflow, což je něco jiného.

[admin]

Vlákno bylo přesunuto do samostatné diskuse. Máte-li pocit, že je ještě potřeba do flamu přispět, přidávejte prosím komentáře do osamostatněné diskuze, nikoliv sem pod článek, se kterým to nesouvisí. Děkuji.

[trekker.dk]

Ne že bych měl něco proti tomu přesunu, ale ten admin, který to udělal, se pod to mohl podepsat a ne přispět jako "anonym".

[Robert Krátký]

a) Nevidím důvod, proč by se měl admin pod takovou akci "podepisovat". Je úplně jedno, který admin to provedl. Všichni za jednoho atd.

b) Kdybys na ten odkaz klikl, hned bys věděl, který admin to udělal

[MaT]

K těm odkazům na literaturu - Heroutova Učebnice jazyka C - je to z nakladatelství Kopp, ne Koop (že by nějaký Koop diskont? .

[Luboš Doležel (Doli)]

Díky, opraveno

[cronin]

Aký je to "operačný systém linuxového typu"?

[pele]

Pravda UNIXoveho je urcite vhodnejsi.

[Atoi()]

Jediny spravny termin je v tomto pripade UNIX-like OS vy hlupaci.

[Elwood]

Kdyby Intel při návrhu stránkování pro 386 měl trochu prozřetelnosti a zavedl u stránek atribut zakazující spouštění kódu, mohli jsme si tyto problémy ušetřit. No co, snad u všech 64bit x86 procesorů už tento atribut je a není problém ho použít. Tak snad do budoucna budou tyto typy útolů podstatně složitější.

[Michal Kubeček]

Intel holt při návrhu 386 asi ještě pořád naivně předpokládal, že se autoři operačních systémů budou chovat rozumně a nebudou plácat instrukční a zásobníkové segmenty přes sebe…

[...Jimmy]

Intelu nezbyl ten posledni bit pro oznaceni varianty +r+w-x, cetl jsem o tom v DPMI specifikaci

[Rob]

A to se jeste dnes/v dobe 386 procesoru dela? Neco jsem o tom cetl v knize z roku 1984, kde se tato "technika", pouzivala na PDP z duvodu usetreni pameti... :). Brr..

[Michal Kubeček]

Kdyby se to nedělalo, jak byste chtěl spouštět kód uložený na zásobníku?

[Rob]

aj. omlouvam se. pochopil jsem to trosku jinak

[petr_p]

To je ovšem celý problém. Současný stav x86_32 takováto zvěrstva umožňuje, ale již neumožňuje je výběrově zakázat.

Kdo jiný potřebuje měnit kód za běhu než multimediální a jinak výkonově vyšinutí jedinci, kteří jsou pro pár cyklů ochotni obětovat cokoliv?

[Michal Kubeček]

Asi jsem se vyjádřil trochu nešťastně. Možnost spouštění kódu uloženého na zásobníku (nebo v datovém segmentu) mi osobně nijak nechybí a samomodifikujícím se kódem jsem se ukájel naposledy na Spectru. Takže jsem asi měl napsat spíš "Kdyby se to nedělalo, nemohl by tento typ útoku fungovat, protože kód na zásobníku by spustit nešlo."

[Filip Jirsák]

Nepoužívá se možnost spouštět kód uložený na zásobníku třeba pro debugery, profilery a podobné nástroje?

[Michal Kubeček]

Pro ty by mělo stačit překrýt instrukční segment datovým. A navíc až když člověk chce ladit nebo profilovat. K překrývání zásobníkového a instrukčního segmentu při normálním běhu produkční aplikace není žádný důvod - kromě pohodlnosti autorů operačních systémů.

[Neuro]

Co to jako je? Je to opsané z knihy Hacking: Umění exploitace a dalsich. Takoveto clanky nemaji zadnou hodnotu. Autoruv prinos neni zadny.

[honza]

no hlavne, ze tvuj prinos je obrovsky. ja autorovi dekuji.

[patok]

no rad jsem si to zopakoval i kdyz je mi jasne, ze tohle uz zacina byt docela dost z mody :)) no ale snad to alespon primeje soucasne zacinajici programatory vic myslet nad kodem..... i sam autor by se mel asi zamyslet nad par vecma v tomhle clanku.... IMHO kdyz mame deklaraci promenne:

char buffer[20];
a nakopirujeme do ni vic znaku, nez je schopna pojmout, tak v ni nebude 20 znaku (bajtu), ale 21, protoze se to indexuje od nuly... Tudiz tohle:

Ve funkci byl vytvořen buffer o velikosti 20 znaků, to je námi očekávaná hodnota. Do tohoto bufferu však vložíme 128 znaků. Z důvodu přetečení paměti program selže.

...neni pravda.

A tohle:

Když se funkce pokusí zapsat 128 bajtů dat do 20 bajtového bufferu, dojde k zapsání 20 bajtů do bufferu a zbylých 108 bajtů přepíše návratovou adresu, ukazatel na rámec a argument funkce.

...je zavadejici, protoze 20bajtovy buffer se definuje jako char buffer[19];.

Nechci byt jedovaty, ale proste mi to prijde u takovehoto clanku trosku trapne. A uz vubec se mi nechce verit ze to bylo v nejake knizce, tak trosku vaham, jestli nahodou neplacam blbosti... precijen jsem spis na ten Python, PHP a BASH ;)

[Jirka]

Jste si tím opravdu jistý?

char buffer[20];

Vytvoří pole 20 charů, čili 20 B. To, že se indexuje od nuly znamená, že nejvyšší index tohoto pole bude 19. Prvků v něm ale bude 20.

20 B bude pořád 20 B. Možná Vám někde řekli, že pokud do pole char pole[20] můžete dát jen 19 hodnot typu char, čili 1 B hodnot a do posledního znak '\0', kdybyste to chtěl vypsat knihovní funkcí jako řetězec.

[patok]

aha, tak to se omlouvam... ja jsem to samozrejme vyzkousel, ale nejakym zahadnym zpusobem mi kompilator do toho buffer[20] vzdycky nakopiroval o 1 znak vic.... tzn. 21 znaku. no vlastne ono to neni tak zahadne... dokud to neprepise tu navratovou hodnotu, tak se to vicemene tvari jako by nic. ted jsem to pro jistotu zkusil znovu a trosku jinak a vazne musim uznat, ze uz jsem mlel k ranu blbosti. ale v zakladu jsem si spletl tedy princip indexovani pole s principem deklarace.
a ano... o tom ukoncovanim retezcu znakem \0 vim, ale neni to primo to co me zmatlo i kdyz mozna to k tomu take prizpelo.

[IK]

Programatorovi bylo sdeleno, ze jeho apartma je v 6-tem patre. Nastoupil do vytahu, stiskl seste tlacitko od spodu s napisem 5, prijel , vystoupil, nemohl ani za nic nalezt svuj pokoj. Ohromne se pozdeji divil, jaktoze ta patra nezacinaji od nuly.

[bn1]

jako bych to už někdy zažil

[Filip Jirsák]

Ale patra jsou číslována od nuly – přízemí (= 1. podlaží), 1. patro (= 2. podlaží), 2. patro (= 3. podlaží) atd. Z toho plyne, že v hotelu byl mezanin

[Jirka]

Nebo ten prográmator byl Pascalista.