Linux vmsplice Local Root Exploit !!!

10.2.2008 05:04 | Přečteno: 14171× | GNU/Linux

Pouhý letmý pohled na ChangeLog nového linuxového jádra 2.6.24.1 musí správce linuxových serverů zneklidnit. Hned v úvodu je zmíněno CVE-2008-0009/10. CVE (Common Vulnerabilities and Exposures) pokaždé představuje bezpečnostní problém. Obvykle pouze minimální, teď je to ale mnohem horší. Na stránkách SecurityFocus lze vedle popisu problému "Linux Kernel Multiple Prior to 2.6.24.1 Multiple Memory Access Vulnerabilities" stáhnout také dva exploity. Jedná se o programy v jazyce C (27704.c a 27704-2.c). Stačí je přeložit a spustit. Z lokálního uživatele se rázem stává root.
Zranitelná jsou všechna vanilla linuxová jádra až do 2.6.24.1.

$ id
uid=1000(raven) gid=1001(raven) groups=29(audio) ...

$ gcc 27704.c

$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7dc6000 .. 0xb7df8000
[+] root

# id
uid=0(root) gid=0(root) groups=29(audio) ...

       

Komentáře

[guns]

a to som sa tesil, ked som kompiloval na serveri 2.6.24 ...

[creon]

a sakra. FC7 2.6.23.14-64.fc7 - rooted

[Marek M.]

Tak updajtuje, mne pod Fedora 8 nejde ani jeden.

[Marek M.]

tak nie ide to :)

[----]

Musí se víckrát...

[rezna]

jojo - to mas z toho ze strkas na server aktualni jadro. chytri a paranoicti lide kteri vi jak se to dela samozrejme instaluji na server bezpecna jadra stara i pul roku, u kterych je prave provereno ze jsou bezpecna, narozdil od tech cerstve vydavanych

[jm]

jojo - to mas z toho ze strkas na server aktualni jadro. chytri a paranoicti lide kteri vi jak se to dela samozrejme instaluji na server bezpecna jadra stara i pul roku, u kterych je prave provereno ze jsou bezpecna, narozdil od tech cerstve vydavanych

Vzhledem k tomu, ze chyba je v jadrech od 2.6.17 vyse, tak tenhle komentar je naprosto mimo misu. No nic.

[al-Quaknaa]

Mě to na serveru s 2.6.20 nefunguje (mám tam morph patchset, což je reiser4 a nějaké další blbosti, ale o bezpečnostní věci se to AFAIK nestaralo). Zeptal bych se, kde dělám chybu, ale ... prostě zkompiluju, spustím, když ani jeden z nich nefunguje, tak je to v suchu, ne?

[al-Quaknaa]

Aha, tak jestli když to hází Segmentation Fault se to hodí do loopu a pak to něco nehezkýho udělá .. tak to zkoušet nebudu. Ale je to teda moc nemilé :/

[David Jaša]

Aktuální 2.6.18-6-686 z Etche je taky náchylné.

[Pavel Půlpán]

To je fór?

[madA]

bohuzel nee, prave sem to odzkousel na debian stable up2date amd64 a i686

[Pavel Půlpán]

Jo to samý u mě...

[Max]

Škoda, že to nefunguje taky na 2.6.8 :-/. Už jsem měl vyhlídlý jeden pěkný servřík kam mám user account(samozřejmě to není můj account :D ).
Zdar Max

[Pavel Půlpán]

Sarge?

[Ignor]

/*
 * jessica_biel_naked_in_my_bed.c
 *
 * Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura.
 * Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca.
 * Stejnak je to stare jak cyp a aj jakesyk rozbite.

[Martin Matějek]

Taky jsem čuměl jak puk ^_^

[Grunt]

 * Dovalim z knajpy a cumim ze Wojta zas nema co robit, kura.
 * Gizdi, tutaj mate cosyk na hrani, kym aj totok vykeca.
 * Stejnak je to stare jak cyp a aj jakesyk rozbite.

Tož poctivé Moravské ručičky sa poznajů hned.

[Grunt]

Ehm, tedy chtěl jsem říct:"Tož šikovné Moravské ručičky sa poznajů hned."

[anonym]

spise slezske ;)

[Grunt]

spise slezske ;)

Těžko říct. Přijde mi to jako mix několika jazyků, jen né českého. Ale převahu samozřejmě uznávám.

[David Jaša]

Odplata za tohle. Pěkně to těm cajzlům všech zemí světa natřeli.

[Grunt]

Tak, tak. I když by mě tedy opravdu zajímalo co to tam v tom Slezsku pijí, jelikož když přijdu z knajpy u nás já, tak jdu většinou spát(a nebo blít, podle toho co je blíž). Pokud ten exploit qaaz psal pod vlivem čehokoliv, tak klobouk dolů a nechtěl bych ho tedy na ulici potkat za střízliva.

[Martin Matějek]

Tak, tak. I když by mě tedy opravdu zajímalo co to tam v tom Slezsku pijí, jelikož když přijdu z knajpy u nás já, tak jdu většinou spát(a nebo blít, podle toho co je blíž). Pokud ten exploit qaaz psal pod vlivem čehokoliv, tak klobouk dolů a nechtěl bych ho tedy na ulici potkat za střízliva.

+1 Třeba je to programátor kalič.

[marbu]

A nebo má zmáknutý dávkování

[Kyosuke]

To se nevylučuje. Třeba uměj psát exploity, ale češtinu se ještě nenaučili.

[Jan Drábek]

Já ani jeden z nich nezkompiluju (gentoo AMD64)

druhý:

/tmp/cclrqIBQ.s: Assembler messages:
/tmp/cclrqIBQ.s:118: Error: Incorrect register `%rax' used with `l' suffix

první:

test.c:30:22: error: asm/page.h: není souborem ani adresářem
test.c: In function ‘main’:
test.c:211: error: ‘PAGE_SIZE’ undeclared (first use in this function)
test.c:211: error: (Each undeclared identifier is reported only once
test.c:211: error: for each function it appears in.)

[pdp7]

Jsem na tom uplne stejne

v jakym baliku je asm/page.h nevi nekdo? Tez gentoo amd64

[jm]

sed -i -e "s:#include <asm/page.h>:#define PAGE_SIZE sysconf(_SC_PAGE_SIZE):"

BTW, 2.6.24.1 opraveno neni!

[pdp7]

Ted to jde no...

[Jiri]

misto page.h dej page_64.h pak to pojede.

[Michal Kubeček]

Mně ten první na AMD64 přeložit nejen jde, ale navíc i funguje (OpenSuSE 10.3, 2.6.22.16-0.2). Druhý nepřeložím. Na 32-bitovém systému s OpenSuSE 10.2 (2.6.22.18-0.8) první funguje, druhý sice přeložím, ale nefunguje (což je vzhledem ke komentáři na začátku celkem logické).

[David Watzke]

dave@amd64 ~/tmp $ gcc -static -Wno-format wtf.c -o wtf -I /usr/src/linux/include/
dave@amd64 ~/tmp $ ./wtf
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2b35dc120000 .. 0x2b35dc152000
[+] root
root@amd64 ~/tmp $

[Shadow]

Debian Etch, 2.6.18-6-686. Druhý exploit mi nefunguje, ale první ano. Tak to je hodně nepříjemné.

[Michal Kubeček]

Ono je u toho druhého na začátku napsáno, že je pro 2.6.23 - 2.6.24. Těžko říct, zda jsou starší proti tomuto útoku odolná, nebo zda by se jen musel exploit upravit.

[jose17]

slackware 12: prvy funguje, druhy ne. celkom pruser, no..

[pdp7]

Tak jsem zkusil zkompilovat ten prvni na mym druhym 32bit poci, funguje, zkompilovana 32bit binarka ale zas nefunguje na 64bitu. Mrkev v zime.

[Martin Matějek]

Stejně tak u mě.

[Limoto]

U mě na 2.6.23.14 fungují oba. Docela jsem čuměl...

[pdp7]

To jsem teda zvedavej, jak dlouho ty exploity budou fungovat. ^_^

[jm]

Vzhledem k tomu, jak casto se a peclive se aktualizuji jadra na spouste serveru, bych rekl ze jeste hodne dlouho...

[Filip Jirsák]

Otázka je, kolik běžných uživatelů má na takovém serveru právo spouštět libovolný kód. Pokud je to nějaký web server, mailserver, Samba, NFS, tak to samo o sobě nevadí. No ale takový web server pro virtuální hosting, kde mají uživatelé přístup i přes ssh, tu už je docela problém…

[jm]

No to je presne ono, musel jsem vsude na hostingu omezit ssh pristup na IP adresy adminu...

[David Jaša]

Pokud má někdo ssh přístup jen kvůli sftp, tak může dobře posloužit shell scponly.

[jm]

Hmmm, tak nevim. scponly je deravy jak reseto... nehlede na to, ze lidi si platej za shell, ne za scponly.

[David Jaša]

nehlede na to, ze lidi si platej za shell, ne za scponly.

Proto jsem dal na začátek tu podmínku.

[Luboš Doležel (Doli)]

Lepší je tu funkci v jádře znefunkčnit, stejně je tam jen od 2.6.17.

[jm]

Taky mam ten pocit, evidentne nikdo nevi co poradne s tim.

[3of5]

To je pekne v haji, tak ten druhy jede ok kernel 2.6.22.6.

[jose17]

2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 00:17:26 CDT 2006 i686 i686 i386 GNU/Linux: skompilovat idu oba, nefunguje ani jeden.

[jm]

No, kdyz je tam napsano, ze je to pro jadra 2.6.17+, to je prekvapeni ze to nejde.

[Tomáš Srnka]

5srnka@eloth ~ $ ./27704
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d7e000 .. 0xb7db0000
Segmentation fault
5srnka@eloth ~ $ uname -a
Linux eloth.gjh.sk 2.6.22-hardened-r8 #6 SMP Wed Dec 5 15:04:38 CET 2007
 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux

hmm

[jm]

No, segmentation fault znamena ze to prave vyprodukovalo kernel oops... Pust to jeste parkrat a dostanes roota, nebo si shodis definitivne server. Cili - stejne vulnerable jako vsechno ostatni.

[Tomáš Srnka]

spustene(10:23), ziskany root(10:23), odhlaseny zo servra(10:24), oznamene adminovi servra(11:03), server skolaboval(11:59) - prestal reagovat postupne na http, ssh, pingy atd., admin isiel do skoly(12:15)... pokracovanie nabuduce

[timeos]

No presne... ja blbec som to spustal na ostrom serveri (v skole)... ping teraz ide (pred chvilou nesiel), ale zbytok (ssh/mail services/web) ani pich. a akcia "admin isiel do skoly" ma este len caka :/

[frEon]

v nedeli?

[Tomáš Srnka]

no, isiel , nastastie to cele fajn dopadlo a server po reebote ide fajn, uz su aj patche voci tomu exploitu nahrane

[Jan Kundrát (jkt)]

Neni pravda, takhle se to napriklad tvari na me konfiguraci hardened jadra:

Feb 10 15:50:36 pstros <0>PAX: suspicious general protection fault: 0000 [#5]
Feb 10 15:50:36 pstros CPU:    0
Feb 10 15:50:36 pstros EIP:    0060:[<00041bd2>]    Not tainted VLI
Feb 10 15:50:36 pstros EFLAGS: 00010202   (2.6.20-hardened-r2 #1)
Feb 10 15:50:36 pstros eax: 00000000   ebx: cdeba800   ecx: ffffffe0   edx: 00000000
Feb 10 15:50:36 pstros esi: d0149e70   edi: 00000001   ebp: 00000000   esp: d0149e3c
Feb 10 15:50:36 pstros ds: 0068   es: 0068   gs: 00d8   ss: 0068
Feb 10 15:50:36 pstros Process a.out (pid: 16502, ti=d0148000 task=cf4ac580 task.ti=d0148000)
Feb 10 15:50:36 pstros Stack: 0007548d 00000001 ffffffe0 00000000 00000001 d0149e90 d0149e70 000769b0
Feb 10 15:50:36 pstros d0149e90 00000000 cae28a40 cdeba800 5a3b1328 d0149f10 d0149e90 00000030
Feb 10 15:50:36 pstros 00000000 c0738c80 00000246 00000000 c0c061e0 00000000 00001000 00000000
Feb 10 15:50:36 pstros Call Trace:
Feb 10 15:50:36 pstros =======================
Feb 10 15:50:36 pstros Code: ff 8f dc 00 00 00 eb dd 90 8b 50 0c ff 4a 04 0f 94 c0 84 c0 75 03 c3
 89 f6 89 d0 ff 52 38 c3 8d 76 00 8d bc 27 00 00 00 00 89 c2 <8b> 00 f6 c4 40 75 12 ff 4a 04 0f
 94 c0 84 c0 75 01 c3 89 d0 e9
Feb 10 15:50:36 pstros EIP: [<00041bd2>]  SS:ESP 0068:d0149e3c

Zadny oops.

[andree]

gentoo: kernel 2.6.21-gentoo-r4 - vulnerable ubuntu(hh): 2.6.22-14-generic - vulnerable (a to som vcera upgradeoval jadro :-/)

paradna nadielka ale typek mohol pockat so zverejnenim...

[andree]

ehm, to ubuntu bolo samozrejme gutsy :o)

[Stevko]

Na hardy to funguje tiež.

[andree]

fedora: 2.6.23.14-64.fc7 (exploit-1); 2.6.23.9-85.fc8 (exploit-2) - taktiez busted..

[R]

Ked som chodil na GJH, tak Eloth bol Celeron 333 :) A raz som z darovanych suciastok zlozil Pentium Pro - to sa tam celkom dlho pouzivalo na vselijake ucely, potom z neho spravili router - mozno to tam este je.

[koffr]

ha ha haaa to zas budou widláci kvičet! :D zejtra se kouknu za žive.cz, co tam vyplodí ten vocass :D

[andree]

a to este pockaj na Nulana

[depka]

nahodou to ma vyhodu, nemusis psat sudo a opisovat zase heslo

[3of5]

+1 rofl

[AsciiWolf]

Distro Gentoo , Kernel 2.6.23-gentoo-r3 první exploit funguje po úpravě (viz. komentáře),druhý se nezkompiluje...

Celkem průser,no

[Piškot]

Dělám něco špatně nebo nemám díru v jádře ? Ubuntu 7.10

Linux notebook 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
piskot@notebook:~/Dokumenty/Hack$ gcc 27704.c 
piskot@notebook:~/Dokumenty/Hack$ id
uid=1001(piskot) gid=100(users) skupiny=4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),
 29(audio),30(dip),46(plugdev),100(users),104(scanner),106(fuse),110(admin)
piskot@notebook:~/Dokumenty/Hack$ gcc 27704-2.c 
piskot@notebook:~/Dokumenty/Hack$ id
uid=1001(piskot) gid=100(users) skupiny=4(adm),20(dialout),21(fax),24(cdrom),25(floppy),26(tape),
 29(audio),30(dip),46(plugdev),100(users),104(scanner),106(fuse),110(admin)

[Limoto]

Po zkompilování to musíš pochopitelně taky spustit

[Piškot]

Hmm jsem blbec a na rootu. Zajímavá situace, ví někdo jak zakázat v systému s sudo gcc a jiné kompilátory ? Nebo to funguje i s jinde kompilovanou binárkou ?

[depka]

to ti vubec nepomuze, muzes tak akorat cekat na patch, nebo ve zdrojacich zakomentovat tu funkci a prekompilovat kernel(mozna), nebo dat starsi kernel

[Piškot]

Nu alespoň uvidíme jak rychle zareagují jednotlivé distribuce.

[jm]

Zatim jaksi neni na co reagovat, nikdo to neopravil... :P

[stanger]

V Archu po dnesnim updatu uz nejde.

[pdp7]

Delas to blbe! Ten exploit se totiz musi jeste spustit

[saly]

Tak to máme ty naše Linuxy bezpečné teda.
Jinak druhý nejde zkompilovat a první ano.
První spuštění Kernel Panic, druhé a třetí psalo nějaký kraviny, tak jsem to překompilovat a funguje to ...
Core 2 Duo - Intel Centrino Duo @ Arch Linux 64-bit, jádro 2.6.24-1.
2.6.24-ARCH #1 SMP PREEMPT Fri Feb 8 22:24:54 CET 2008 x86_64 Intel(R) Core(TM)2 Duo CPU T5250 @ 1.50GHz GenuineIntel GNU/Linux

[kozzi]

tak aktualizuj arch uz to ma opraveny

[saly]

Just updated :) Arch Linux rulezzzz!!!!!!

[Jendа]

2.6.18-5-486 z Etche - jde. SAKRA! Kdy bude oprava?

[andree]

no ono oprava uz je, len nie je asi backportnuta do ostatnych verzii jadier, zatial - v distribuciach... diff

[2008]

V 2.6.24.1 to stale nie je opravene.

[Jirka P]

Chcete říct, že changelog lže, anebo že ten patch to neopravuje?

[2008]

Mam 2.6.24.1.

-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2fd64e58e000 .. 0x2fd64e5c0000
[+] root

[ynezz]

Je treba jeste aplikovat tento patch http://www.gossamer-threads.com/lists/linux/kernel/877265

[jm]

Ne!!!

[2008]

-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x100000000000 .. 0x100000001000
[+] page: 0x100000000000
[+] page: 0x100000000038
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4038
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0x2fd64e58e000 .. 0x2fd64e5c0000
[+] root

[Mrkva]

Nevím, ale tenhle: http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c je pořád funkční.

[2008]

Je mozne, ze ta chyba je sposobena umyselne niektorym s vyvojarov jadra,

[jose17]

http://thread.gmane.org/gmane.linux.kernel/637339

[jm]

Zatim jsem tam zadny funkcni patch nenasel. Naopak jeden z nich je regresi jiz opravene druhe diry ve vmslice().

[David Jaša]

Kdyby jenom -5, ona je náchylná i -6...

[alblaho]

Tak tohle je nejhustší záležitost, co jsem na Linuxu zažil.

Proč se víc nepoužívá "stabilní" řada jejíž poslední release je 2.6.16.60?

[Mrkva]

Ono na serverech asi pouziva, ale treba ja na desktopu pouzivam vetsinou nejnovejsi jadro... Ja vim, muzu si za to sam

[alblaho]

No ono používat několik let staré jádro asi není žádný med. Protože ovladače a tak, na desktopu obzvlášť. Nevím, jak je na tom 2.6.16 právě s backportováním ovladačů...

[Martin Hudec]

Mas pravdu. Lenze ako casto mas desktop dostupny zvonku z internetu, a takisto, kolko ludi ma konto na tvojom desktope? Ja svoj desktop zvonku dostupny nemam a jedine konto je tam moje. Ina situacia je to uz so servermi :).

[kozzi]

No na svem desktope mam asi 5 uctu pro kamose primo dalsich 5 uzivatelu mam v openldap databazi. Pristup ke mne je z venci pres ip adresu 213.29.1.223 heslo u vetsiny je polda, polda11 popripade fresh12, takze kdokoliv se muze pres ssh propjit a udelat ze sebe roota. Takze i muj desktop je v nebezpeci. Takze jsem rad ze uz mam tuto bez chybu opravenou, teda jeste ne musim jeste dat restart pc, ale to dam az nekdy jindy ted jsem zatim vypnul sshd

[Grunt]

No ono používat několik let staré jádro asi není žádný med. Protože ovladače a tak, na desktopu obzvlášť. Nevím, jak je na tom 2.6.16 právě s backportováním ovladačů...

A právě z toho důvodu by měly být ovladače od jádra odtrženy do nějakého driverspace(klidně by mohli zůstat i v kernelspace, pokud by bylo zaručeno pomocí nějakého API, že téměř jakýkoliv ovladač přeložím s jakýmkoliv jádrem) a vytvořeno nějaké ABI.

[Heron]

+1

[Manarinka]

+1

Zlaté windows, co?

[Grunt]

Zlaté windows, co?

Tak, tak. Čím hlouběji člověk do Linuxu vrtá, tím víc si uvědomuje, jak geniálně to mají vyřešeno u konkurence od, které utekl.

[ronny]

jojo.. tam takove chyby opravuji do ... mesice :))) tu to trvalo cele 3dny!

[Grunt]

jojo.. tam takove chyby opravuji do ... mesice :))) tu to trvalo cele 3dny!

No tak opravu chyb jsem zrovna nemyslel. V tomto případě není co řešit. Ale ty drivery, nebo vývoj jádra…

tu to trvalo cele 3dny!

No já nevím, ale zatím se mi v aktualizacích nové jádro neobjevilo. A 3 dny málo nejsou a šlo by to i zrychlit.

[ronny]

no to uz zalezi na distru ja v archu to mam uz od nedele

[Grunt]

no to uz zalezi na distru

No právě. To je to co mě ser…štve. Kdo tvrdí "Linux je jen jeden", ten lže.

[ronny]

Vsak pokud si chtel mohl sis to opravit sam popr. na ten den vypnout sshd :)

[Grunt]

Vsak pokud si chtel mohl sis to opravit sam popr. na ten den vypnout sshd

Jo, to mohl, ale bohužel existuje spíše více lidí, kteří ani nevědí, že nějaký takový bug byl. A navíc jsem zastáncem automatizace(no nebylo by pěkné kdyby se to automaticky ihned za těch 24hodin od objevení automaticky záplatovalo na serverech bez nutnosti znovunačtení jádra?).

[ronny]

no kolik lidi o te chybe nevi a kolik lidi aktualizuje jednou za tyden ja treba denne aktualizuju 3x :D

[Grunt]

a kolik lidi aktualizuje jednou za tyden

http://www.abclinuxu.cz/forum/show/213889#270:

Kdyby to fungovalo tak, že by mě automaticky upozornili na to, že je kritický bug a jako opravu ihned nabídli modul který stačí stáhnou a natáhnou do paměti, vůbec bych si nestěžoval. A pokud by se to samo stahovalo a načítalo do paměti, zvláště pak u serverů…

[ronny]

u serveru by si bugy v distru mel hlidat.. a snazit je co nejdrive opravit

[Grunt]

u serveru by si bugy v distru mel hlidat…

Kdo?

[ronny]

jejich administratori jsou to prece oni kdo jsou zodpovedni za chod a bezpecnost serveru nebo ne?

[David Watzke]

Ne, to by byl backdoor

[xkucf03]

S elektronickým podepisováním teoreticky ne. Když si instaluješ nové jádro z balíčku, tak ho taky moc nezkoumáš. Je prakticky jedno, jestli se to děje automaticky nebo ručně.

(Protože i když si aktualizuješ systém sám, tak stejně nevíš, co je v těch zkompilovaných programech).

[Grunt]

Ne, to by byl backdoor

Co by byl proboha backdoor?

[Pavel Půlpán]

Distro != Linux... je na vývojářích jak hejbnou kostrou a zapatchujou to. Ve Vanilla byla opravná verze včera ráno.

[Grunt]

Distro != Linux

To je fakt. Už by se mělo konečně přestat s blbostmi jako je distribuování a konečně začít s užitečnými věcmi jako je sjednocování(či spíše vytváření systému jednotné správy).

je na vývojářích jak hejbnou kostrou a zapatchujou to.

No právě. Vývojáři jádra, vývojáři distribučního jádra na distribuci ABC verze x.y.z. 1 patch a 1000 různých míst kde ho aplikovat.

Ve Vanilla byla opravná verze včera ráno.

A na Hardy Heronu mi exploit funguje ještě dnes.

[Luboš Doležel (Doli)]

První odstavec: bla, bla, bla. Kravina. Diverzita je i prospěšná věc.

Druhý odstavec: ještě větší blábol.

A třetí odstavec: koho to zajímá. Pokud vám ten problém opravdu vadí (tzn. někdo na vás bude lokálně útočit), tak by neměl být problém nahodit jádro vlastní.

[Grunt]

Diverzita je i prospěšná věc.

A opak netvrdím, ale nic by se nemělo přehánět. Zrovna v tomto případě, kdy je potřeba rozšířit jeden patch mi diverzita příliš prospěšná nepřijde. Ani mi nevadí ta diverzita spíše jako absence alespoň jednoho standardizovaného a uznávaného způsobu šíření záplat(ale není to jen o záplatách).

Druhý odstavec: ještě větší blábol.

Proč? Když si to shrnu, tak co distro, to jiné jádro. A povětšinou menší než 2.6.24.2, takže buď si to záplatuje každý u svého jádra sám a nebo se bude čekat než se ta záplata ve vanille dostane i do nižších verzí(backportovat?). Jednou patchovat prostě nestačí.

A třetí odstavec: koho to zajímá.

Mě a možná i ostatní uživatele distribuce Ubuntu.

Pokud vám ten problém opravdu vadí (tzn. někdo na vás bude lokálně útočit), tak by neměl být problém nahodit jádro vlastní.

Pro mě ne, ale tady nejde přece o mě. Tady jde o princip. Já si klidně zkompiluji modul, použiji jiný exploit, apod., ale je zde i větší množství uživatelů co nemají ponětí o nějakém bugu, natož potom co je to kompilace nebo jádro.

jádro vlastní.

Né všichni mají Gentoo.

[Filip Jirsák]

Zrovna v tomto případě, kdy je potřeba rozšířit jeden patch mi diverzita příliš prospěšná nepřijde.

Ale vždyť v linuxu to není „je potřeba rozšířit jeden patch“. Takhle je to ve Windows, a je známé, jak spousta počítačů s Windows ty patche nemá. V linuxu to je tak, že si s tím má poradit správce. Někdo si poradí tak, že okamžitě deaktivuje sshd, překompiluje jádro s vyřazenou příslušnou funkcí a vrátí zpět sshd. Někdo si počká na oficiální patch pro vanilkové jádro a překompiluje si ho, a někdo si počká až na otestované distribuční jádro. Podle toho, co komu vyhovuje. Chtít ihned otestovaný distribuční balíček je nesmysl. Můžete to mít buď rychle, nebo otestované – obojí najednou nelze.

[Grunt]

Ale vždyť v linuxu to není „je potřeba rozšířit jeden patch“.

Přesně tak, je toho mnohem více.

Takhle je to ve Windows, a je známé, jak spousta počítačů s Windows ty patche nemá.

Windows do toho prosím netahejme. Ten toho s OSS mnoho společného nemá.

V linuxu to je tak, že si s tím má poradit správce. Někdo si poradí tak, že okamžitě deaktivuje sshd, překompiluje jádro s vyřazenou příslušnou funkcí a vrátí zpět sshd. Někdo si počká na oficiální patch pro vanilkové jádro a překompiluje si ho, a někdo si počká až na otestované distribuční jádro. Podle toho, co komu vyhovuje.

Bohužel, čim více se rozšiřují svobodné systémy do běžných systémů, tím více je "správců" co ani nevědí co to ssh je.

Chtít ihned otestovaný distribuční balíček je nesmysl. Můžete to mít buď rychle, nebo otestované – obojí najednou nelze.

Samozřejmě po nikom nechci ihned nový kernel, ovšem nevím co je potřeba testovat na vyřazení funkce vmsplice z provozu(resp. přidání kontroly zda-li zapisuje do správného paměťového bloku). Alespoň ten modul mohl se mohl stáhnou a ihned natáhnout do paměti. A až by přišlo nové jádro, tak by se balíček s modulem jednoduše smazal.

[Filip Jirsák]

Ale vždyť v linuxu to není „je potřeba rozšířit jeden patch“.

Přesně tak, je toho mnohem více.

Ne, není. Linux jako takový funguje na tom principu, že si správce stáhne, co potřebuje, ne že mu někdo něco tlačí. Pokud nějaká distribuce svoje aktualizace tlačí, je to její věc, ale není to věc obecně linuxu. Takže obecně od linuxu neočekávejte, že bude mít někdo potřebu nějaký patch „šířit“. Pokud to dělá nějaká vaše distribuce, a ta vám podle vás aktualizaci nenatlačila dostatečně rychle, stěžujte si na tu konkrétní distribuci.

Windows do toho prosím netahejme. Ten toho s OSS mnoho společného nemá.

To není věc OSS nebo uzavřeného software. To je příklad toho, jak to funguje, když o tom, jaký patch a kdy bude nasazen nerozhoduje administrátor, ale nějaké „ústředí“.

Bohužel, čim více se rozšiřují svobodné systémy do běžných systémů, tím více je "správců" co ani nevědí co to ssh je.

U těch bude ale zranitelnost pár dní starou chybou v jádře tím nejmenším bezpečnostním problémem.

Samozřejmě po nikom nechci ihned nový kernel, ovšem nevím co je potřeba testovat na vyřazení funkce vmsplice z provozu(resp. přidání kontroly zda-li zapisuje do správného paměťového bloku). Alespoň ten modul mohl se mohl stáhnou a ihned natáhnout do paměti. A až by přišlo nové jádro, tak by se balíček s modulem jednoduše smazal.

Cože, automaticky bez vědomí administrátora deaktivovat nějakou funkci v jádře?! To doufám nebylo myšleno vážně. Pokud někdo potřeboval opravu rychle, měl možnost si jádro zkompilovat sám. Pokud někdo tu opravu tak rychle nepotřeboval, nepotřebuje nějaký hack do jádra, který mu třeba znefunkční jedinou aplikaci, která už stihla začít tuhle funkci používat, ale potřebuje normální opravu – otestovanou jak samotnou, tak v souvislosti s celým systémem.

[Grunt]

Ne, není. Linux jako takový funguje na tom principu, že si správce stáhne, co potřebuje, ne že mu někdo něco tlačí. Pokud nějaká distribuce svoje aktualizace tlačí, je to její věc, ale není to věc obecně linuxu. Takže obecně od linuxu neočekávejte, že bude mít někdo potřebu nějaký patch „šířit“.

Možná jsme se trochu nepochopili. Tlačení záplaty do počítače, tak jak to dělá Windows moc rád nemám a odsuzuji ho, ale kdyby mi třeba tuto záplatu jako modul aktualizační systém nabídl, neváhal bych.

Pokud to dělá nějaká vaše distribuce, a ta vám podle vás aktualizaci nenatlačila dostatečně rychle, stěžujte si na tu konkrétní distribuci.

A už jsme zase u toho, distribuce…

To není věc OSS nebo uzavřeného software. To je příklad toho, jak to funguje, když o tom, jaký patch a kdy bude nasazen nerozhoduje administrátor, ale nějaké „ústředí“.

A jak tedy?

U těch bude ale zranitelnost pár dní starou chybou v jádře tím nejmenším bezpečnostním problémem.

To pochybuji. Pokud má vytvořen účet od nějakého chytřejšího kamaráda, který mu spravuje PC.

Cože, automaticky bez vědomí administrátora deaktivovat nějakou funkci v jádře?! To doufám nebylo myšleno vážně.

Proč bez vědomí?

Pokud někdo potřeboval opravu rychle, měl možnost si jádro zkompilovat sám.

Na binární distribuci? To už je vcelku problém.

[Filip Jirsák]

Možná jsme se trochu nepochopili. Tlačení záplaty do počítače, tak jak to dělá Windows moc rád nemám a odsuzuji ho, ale kdyby mi třeba tuto záplatu jako modul aktualizační systém nabídl, neváhal bych.

To je pak ale zase otázka vaší distribuce. Jestli vám ten modul nenabídla včas, porozhlédněte se, zda by vám jiná nevyhověla lépe. Jádro jako takové žádný systém sebeaktualizací nemá (a doufám, že ani nikdy mít nebude). Kdybyste to chtěl řešit externě, budete znova vymýšlet balíčkovací systém distribuce a způsob aktualizace balíčků.

To pochybuji. Pokud má vytvořen účet od nějakého chytřejšího kamaráda, který mu spravuje PC.

V takovém případě ho tahle chyba pravděpodobně nebude trápit. A kdyby ano, tak by se měl asi holt postarat chytřejší kamarád.

Cože, automaticky bez vědomí administrátora deaktivovat nějakou funkci v jádře?! To doufám nebylo myšleno vážně.

Proč bez vědomí?

Myslel jsem automatickou aktualizaci à la Windows. Ale stejně nevím, jaká je tedy vaše představa – buď správce o dané chybě ví, a bude aktivně shánět opravu. Nebo o ní neví, pak ale asi opravu tak nutně nepotřebuje – a pak to bude stejně aktualizace stylem Další – Další – Další – Dokončit, tím pádem to musí být otestovaná aktualizace o které se ví, že v žádném případě nic nerozhodí. Nebo vám by k něčemu bylo, kdyby vám aktualizační systém 12 hodin po objevení té chyby, aniž byste o ní věděl, oznámil, že má aktualizaci, která to možná opraví, a možná taky něco rozbije ještě daleko víc?

Na binární distribuci? To už je vcelku problém.

Za mých mladých let šlo jádro zkompilovat v jakékoli distribuci. To už jsou opravdu takové distribuce, že nemají gcc, další nástroje a autotools? Respektive že tam zdrojáky jádry (ať už vanilku nebo s distribučními patchi) nemáte jako balíček?

[Grunt]

To je pak ale zase otázka vaší distribuce. Jestli vám ten modul nenabídla včas, porozhlédněte se, zda by vám jiná nevyhověla lépe.

Aha a která?

Jádro jako takové žádný systém sebeaktualizací nemá (a doufám, že ani nikdy mít nebude). Kdybyste to chtěl řešit externě, budete znova vymýšlet balíčkovací systém distribuce a způsob aktualizace balíčků.

Proto říkám, že všechny balíkovací systémy by se měli zrušit a používat se jeden, který by ctili všechny významné distribuce.

V takovém případě ho tahle chyba pravděpodobně nebude trápit. A kdyby ano, tak by se měl asi holt postarat chytřejší kamarád.

Trápit nebude do doby než se kamarád dostane na roota.

Myslel jsem automatickou aktualizaci à la Windows. Ale stejně nevím, jaká je tedy vaše představa

No v podstatě jen balíček s tím modulem co to opraví jako aktualizace. Akorát ještě nějak upozornit toho "Správce aktualizací"(otevřeným spojením,IGMP něco už by se našlo).

Nebo vám by k něčemu bylo, kdyby vám aktualizační systém 12 hodin po objevení té chyby, aniž byste o ní věděl, oznámil, že má aktualizaci, která to možná opraví, a možná taky něco rozbije ještě daleko víc?

Proč by něco rozbíjelo?

Za mých mladých let šlo jádro zkompilovat v jakékoli distribuci. To už jsou opravdu takové distribuce, že nemají gcc, další nástroje a autotools? Respektive že tam zdrojáky jádry (ať už vanilku nebo s distribučními patchi) nemáte jako balíček?

Pro to aby jste mohl něco patchovat musíte mít vanilku a na tu dostat patch opravný a patche distribuce. Pivo když to dáte. A navíc tím přicházíte o možnosti využívání driverů z balíkovacího systému,atd. A už vidím výraz kamaráda, kterému se zrovna dostal brácha na roota, když mu řeknu "zkompiluj si jádro".

[michich]

Proč by něco rozbíjelo?

Ty myslíš, že autor patche je vždy neomylný a že promyslel všechny možné dopady změny?

Pro to aby jste mohl něco patchovat musíte mít vanilku a na tu dostat patch opravný a patche distribuce.

Opravný patch můžeš aplikovat na distribuční zdrojáky.

[Filip Jirsák]

Proto říkám, že všechny balíkovací systémy by se měli zrušit a používat se jeden, který by ctili všechny významné distribuce.

Za prvé, je to dost nereálné. Za druhé, když by pak zaspal tenhle jeden balíčkovací systém, neměl by opravu nikdo. Nebo kdyby se podařilo do tohohle systému propašovat backdoor, měly by ho všichni.

Proč by něco rozbíjelo?

To už tak bývá. Ty nejnevinnější změny v kódu skoro pokaždé rozbijou něco zásadního. Bez otestování se na to nepřijde.

Pro to aby jste mohl něco patchovat musíte mít vanilku a na tu dostat patch opravný a patche distribuce.

Ale kdepak. Stáhnete si zdojáky distribučního (už opatchovaného) jádra i s distribuční konfigurací, na to aplikujete patch (který půjde aplikovat bez konfliktů, pokud se zrovna v téhle části kódu nevrtal nějaký patch z distribuce – a kdyby se v ní vrtal, dost možná už by se na tu chybu přišlo dávno). A pak už stačí dát jenom make …

A už vidím výraz kamaráda, kterému se zrovna dostal brácha na roota

Tak to má spravovat brácha, když tomu rozumí líp…

[Grunt]

Za prvé, je to dost nereálné.

Proč? Kdyby byl jeden způsob zapisování aplikací po spuštění, jednotný zápis konfiguračních souborů, atd., tak mi to až tak nereálné nepříjde.

Za druhé, když by pak zaspal tenhle jeden balíčkovací systém, neměl by opravu nikdo.

No tak to by asi neměl zaspávat.

Nebo kdyby se podařilo do tohohle systému propašovat backdoor, měly by ho všichni.

Kdežto, když se to podaří teď dostat do repositářů Ubuntu, tak budou mít Gentooisti klid.

To už tak bývá. Ty nejnevinnější změny v kódu skoro pokaždé rozbijou něco zásadního. Bez otestování se na to nepřijde.

No v tomto konkrétním případě, kdy se přidá jen kontrola zda-li má právo vmsplice do té a té adresy zapisovat, není moc co rozbíjet. Ale jinak souhlasím. Jednotný balíčkovací systém by jen přispěl k tomu, že to není třeba testovat 10x.

Ale kdepak. Stáhnete si zdojáky distribučního (už opatchovaného) jádra i s distribuční konfigurací, na to aplikujete patch (který půjde aplikovat bez konfliktů, pokud se zrovna v téhle části kódu nevrtal nějaký patch z distribuce – a kdyby se v ní vrtal, dost možná už by se na tu chybu přišlo dávno). A pak už stačí dát jenom make …

petrvlasic@petr:/usr/src/linux-source-2.6.22$ sudo patch -p1 < patch
patching file fs/splice.c
Hunk #1 FAILED at 1179.
Hunk #2 FAILED at 1390.

a to není první patch, který jsem zkoušel. Proto říkám, že je potřeba vanilka a na ni dostat oba patche(jenže to jde také jak kdy, protože furt si ten druhý patch stěžuje, že to nevypadá tak jak má). A jak říkám, na binárních distrech není vlastní jádro to pravé ořechové.

Tak to má spravovat brácha, když tomu rozumí líp…

Na každý i sebeblbější argument, odpověď. To bych chtěl umět…

[David Jaša]

Proč? Kdyby byl jeden způsob zapisování aplikací po spuštění, jednotný zápis konfiguračních souborů, atd., tak mi to až tak nereálné nepříjde.

To je jak snaha o sjednocení církví. Ty se shodnou nejvýš na společném znění (části) výchozího textu, ale sjednocovat dál se nebudou.

[Grunt]

Ty se shodnou nejvýš na společném znění (části) výchozího textu

Kéž by alespoň to.

[Honza Jaroš]

Proč? Kdyby byl jeden způsob zapisování aplikací po spuštění, jednotný zápis konfiguračních souborů, atd., tak mi to až tak nereálné nepříjde.

Tohle mi trošku připomíná výrok: Debe měla tetička kóle, bela by stréček...

[David Watzke]

je zde i větší množství uživatelů co nemají ponětí o nějakém bugu, natož potom co je to kompilace nebo jádro.

Takovým uživatelům to ale může bejt jedno. S takovými znalostmi patrně neprovozují SSH server a ani víceuživatelský systém, který je třeba mít brutálně zabezpečený (max. rodinný počítač, jehož ostatní uživatelé si patrně nestáhnou a nezkompilujou tu rychlejší verzi su, která neotravuje s dotazem na heslo a pokud jo, můžou to rovnou opravit).

[Grunt]

Takovým uživatelům to ale může bejt jedno.

A také to jedno je(vždyť GNU/Linux je mnohem bezpečnější než ten fuj-fuj systém od kterého jsem utekl a s uživatelskými právy si tak max. může smazat svůj domovský adresář). Teda do doby než kamarád, kterému jste také vytvořili účet najde a zkopíruje si váš adresář s těžce nakradeným warezem, pracně , skrze torrenty, přeceděnou hudbou a filmy, ukořistěným péčkem,…

S takovými znalostmi patrně neprovozují SSH server a ani víceuživatelský systém

Bohužel SSH buď defaultně běží nebo si jej většina lidí zapíná. A běžného uživatele defaultně cpe každá distribuce.

[Petr "Glubo" Sýkora]

Nicméně, to že běží ssh nic neznamená v kontextu této díry. Ono totiž nejdřív se člověk musí nalogovat njako nějaký uživatel, tedy mít běžný účet na daném stroji, a teprve pak může využít toho vylepšeného su.

A kolik "bežných uživatelů" rozdává účty na svém počítači cizím lidem?

[xkucf03]

tak tak, linux má těch pojistek hodně a když jedna praskne, tak to ještě nic moc neznamená. Např. když má někdo sftp přístup, tak mu nemusím dávat shell. Ale tím nechci zlehčovat závažnost tohoto exploitu.

Problém to může být (resp. mohl být) na školních nebo komunitních serverech. Ale tam by zase člověk byl sám proti sobě, kdyby hackoval / shazoval službu kterou sám používá

[Grunt]

A kolik "bežných uživatelů" rozdává účty na svém počítači cizím lidem?

To zní jako anketní otázka, protože já jich znám hodně.

[Heron]

Je otázné, co Petr myslel tím slovem "cizí". Věřím, že se nenajde mnoho lidí, kteří na svém počítači dají účet člověku, kterého neznají (=cizí).

Jinak je nemálo lidí, kteří na svém PC vytvoří účet pro své známé. Předpokládám, že právě těchto lidí znáš hodně. Já také. I u mě má mnoho přátel účet a rozhodně se nebojím, že by u mě použili tento exploit. Protože přátelství je důležitější než se dostat na roota (kde stejně udělají hovno, protože data jsou zálohovaná a tajná data jsou i šifrovaná).

[Grunt]

Je otázné, co Petr myslel tím slovem "cizí". Věřím, že se nenajde mnoho lidí, kteří na svém počítači dají účet člověku, kterého neznají (=cizí).

Jinak je nemálo lidí, kteří na svém PC vytvoří účet pro své známé. Předpokládám, že právě těchto lidí znáš hodně.

Přesně tak.

Já také. I u mě má mnoho přátel účet a rozhodně se nebojím, že by u mě použili tento exploit.Protože přátelství je důležitější než se dostat na roota

Vždyť nemluvím o mně.

(kde stejně udělají hovno, protože data jsou zálohovaná a tajná data jsou i šifrovaná).

…ne všichni používají GNU systémy jen na serveru.

[petr_p]

Diverzita je i prospěšná věc.

A opak netvrdím, ale nic by se nemělo přehánět. Zrovna v tomto případě, kdy je potřeba rozšířit jeden patch mi diverzita příliš prospěšná nepřijde.

Ne. Vy se rozčilujete, že váš distributor není tak rychlý jako ten můj. Podívejte se na to z mé strany: Kdybych musel požívat vaši distribuci, tak bych v systému pořád měl díru.

Tudíž v tento moment je rozmanitost výhodná aspoň pro někoho.

[Grunt]

Vy se rozčilujete, že váš distributor není tak rychlý jako ten můj.

Přesně tak.

[Pavel Půlpán]

A co by jsi chtěl sjednocovat? LSB už tu máme! A co se týče verzí... je to trošku složitější.

[Grunt]

A co by jsi chtěl sjednocovat?

Ani né tak sjednocovat jako standardizovat.

LSB už tu máme!

No jo, ale to já nevěděl. Přesouvám se brečet na jiný hrob.

A co se týče verzí... je to trošku složitější.

Proč?

[Pavel Půlpán]

Nemůžeš přece vývojářům nutit, jaké verze softwaru mají ve svém distru používat.

[xkucf03]

1. Rozmanitost je hezká a podporuje kreativitu. Ale zase na druhou stranu, když si představím, že by se spojili síly, vybrala by se jedna distribuce a ta se vypilovala - pracovalo by na tom mnohem víc lidí. Podobně jako FreeBSD nemá distribuce a všichni vývojáři dělají na jednom systému. Ať už by se za výchozí distribuci vybrala kterákoli z běžně používaných (SUSE, Ubuntu...), věřím, že bychom se posunuli o hodně dopředu a Linux (plus to kolem, co dělají dnes distribuce) by byl o hodně kvalitnější. (ale to se stejně asi nestane, protože každý si bude radši hrát na svém písečku)

2. Nemůžeš přece vývojářům nutit, jaké verze softwaru mají ve svém distru používat.

   Bylo by hezké, kdyby existoval standardní způsob, jak vedle sebe provozovat různé verze programů a knihoven. (za standardní nepovažuji to, když si člověk ručně zkompiluje program s nějakým prefixem a pak si ho krkolomně spouští).

[Shadow]

když si představím, že by se spojili síly, vybrala by se jedna distribuce a ta se vypilovala - pracovalo by na tom mnohem víc lidí

Jen pár drobných otázeček:

1) kdo a na základě čeho (a jakým právem) by takovou distribuci vybral?

2) kdyby taková distribuce přeci jen byla vybrána, kde berete tu jistotu, že vývojáři ostatních distribucí by na ní začali pracovat?

3) kdo a jak by zajistil, aby vývojáři nemohli pokračovat ve výoji těch ostatních?

Podobně jako FreeBSD nemá distribuce a všichni vývojáři dělají na jednom systému.

A FreeBSD je díky tomu také o to úspěšnější než GNU/Linux a má také mnohem více vývojářů... aha... počkat... ono je to trochu jinak...

Mimochodem, znáte PC BSD či DesktopBSD? Jak byste je označil? Já osobně je považuji za distribuce FreeBSD... jsou sice dvě (o kterých vím), ale očividně existují.

ale to se stejně asi nestane, protože každý si bude radši hrát na svém písečku

Možná by bylo dobré zamyslet se nad tím, proč je tomu tak.

[xkucf03]

kdo a na základě čeho (a jakým právem) by takovou distribuci vybral?

Jedinou autoritou je asi Linus. Ale stejně jsem více méně smířen s tím, že nějaké sjednocení Linuxu je utopie.

na základě čeho

To by nebylo až tak důležité, protože ty přední distribuce jsou hodně vyrovnané a rozdíly mezi nimi nejsou nepřekonatelné. Jde spíš o politiku, kdo s kým kamarádí a kdo je na co zvyklý.

kdyby taková distribuce přeci jen byla vybrána, kde berete tu jistotu, že vývojáři ostatních distribucí by na ní začali pracovat? kdo a jak by zajistil, aby vývojáři nemohli pokračovat ve vývoji těch ostatních?

V tom nikomu bránit nejde. Ale zdrojáky FreeBSD si taky můžu vzít a zítra vydat novou "distribuci" - akorát ve světě FreeBSD to není zvykem a lidé spíš spolupracují na jednom projektu. Jinak bychom tu měli KDEBSD, GnomeBSD, EduBSD...

Mimochodem, znáte PC BSD či DesktopBSD?

Znám, PC-BSD jsem dokonce rok používal na desktopu jako hlavní OS Nazval bych je nadstavbami. Rozdíl je v tom, že FreeBSD je provozuschopný operační systém, zatímco linuxové jádro si samo o sobě nenainstaluji a nespustím. Ty nadstavby přidávají něco navíc, ale uvnitř je pořád FreeBSD, stačí sledovat, jak často je odkazována jeho dokumentace, i když se řeší problémy PC-BSD (prostě je to FreeBSD + něco navíc).

Možná by bylo dobré zamyslet se nad tím, proč je tomu tak.

Čím myslíš, že to je? Já nevím, ale tipoval bych, že záměr to není, spíš neschopnost se dohodnout.

[Shadow]

Jedinou autoritou je asi Linus. Ale stejně jsem více méně smířen s tím, že nějaké sjednocení Linuxu je utopie.

Z mého pohledu i naprostý nesmysl.

To by nebylo až tak důležité, protože ty přední distribuce jsou hodně vyrovnané a rozdíly mezi nimi nejsou nepřekonatelné. Jde spíš o politiku, kdo s kým kamarádí a kdo je na co zvyklý.

U distribucí s podobným zaměřením (Mandriva, OpenSUSE) jsou rozdíly méně podstatné (i když v případě hypotetického sjednocování by asi i tak hrály důležitou roli), avšak u distribucí s různým zaměřením (Gentoo vs Mandriva) jsou rozdíly skutečně nepřekonatelné.

V tom nikomu bránit nejde. Ale zdrojáky FreeBSD si taky můžu vzít a zítra vydat novou "distribuci" - akorát ve světě FreeBSD to není zvykem a lidé spíš spolupracují na jednom projektu. Jinak bychom tu měli KDEBSD, GnomeBSD, EduBSD...

Máme tu ale PC-BSD a DesktopBSD. Kromě toho, v tomto případě bych spíše řekl, že důvodem je málo vývojářů (a to, že je patrně pro vývojáře snadnější, aby se přidal k nějaké distribuci GNU/Linuxu, než aby spáchal odnož FreeBSD). Kdyby mělo FreeBSD tolik vývojářů, jako GNU/Linux... no, to je námět na další spekulace a hypotézy.

Znám, PC-BSD jsem dokonce rok používal na desktopu jako hlavní OS Nazval bych je nadstavbami.

Já bych je klidně označil za distribuce. Odnože. Varianty. To je jedno. Podstatné je, že i tady k jistému štěpení dochází.

Čím myslíš, že to je? Já nevím, ale tipoval bych, že záměr to není, spíš neschopnost se dohodnout.

Pokud se jedná o firmy, tak tam je jasné, že každá sleduje svůj záměr. A u vývojářů dobrovolníků je to podobné. Každý pracuje na tom, co mu vyhovuje, co je nejblíže jeho představě optimální distribuce. Což je u každého něco jiného.

Však se podívejte kolem sebe. Také nemáme jeden model auta, jeden typ nože nebo jeden typ PC. Rozmanitost je všude kolem nás. Každý má jiné potřeby a každému vyhovuje něco jiného. Svět GNU/Linuxu je toho odrazem.

[Grunt]

V podstatě jste lépe formuloval to co snažím celou dobu říct a souhlasím, ale s výhradami. Jedna univerzální distribuce určitě není to pravé ořechové. Situace kdy si každý vybere, každý co chce(Ubuntu těm co chtějí mít jednoduché ovládání, povětšinou téměř vše automatizované a nemají příliš zájem se učit,Gentoo těm kteří chtějí mít svůj systém plně pod kontrolou a chtějí se učit,Debian na server…) není špatná. Ale to, že se jeden konfigurační soubor v každé distribuci zapisuje v jiné syntaxi a na jiné místo, to že si každý používá jiný způsob k distribuci binárních ovladačů, to že každá distribuce má svůj unikátní klikací nástroj na nastavování, a to že <a teď bych mohl pokračovat donekonečna> mi přijde prostě mírně řečeno uhozené.

[Grunt]

Nemůžeš přece vývojářům nutit, jaké verze softwaru mají ve svém distru používat.

To je nevýhoda OSS, nemůžu nikomu nic nutit. Proto by měli být alespoň vytvořeny standardy, které by se měli dodržovat(nechtěl jsem říct nutit).

[Pavel Půlpán]

Vidíš... já to naopak beru jako výhodu?!

Uživatel chce stabilní odladěný systém: Zvolí distro, kde se dbá na "jedna release = jedna verze" a dále se už jen opravují chyby. Časem samozřejmě software stárne a tak příjde daší release.
Uživatel chce vždy aktuální systém: Zvolí distro s rolling-updates a sem tam nějaká buga je prostě vedlejší efekt, s kterým je smířený.

[Grunt]

Vidíš... já to naopak beru jako výhodu?!

Uživatel chce stabilní odladěný systém: Zvolí distro, kde se dbá na "jedna release = jedna verze" a dále se už jen opravují chyby. Časem samozřejmě software stárne a tak příjde daší release.
Uživatel chce vždy aktuální systém: Zvolí distro s rolling-updates a sem tam nějaká buga je prostě vedlejší efekt, s kterým je smířený.

Nemyslel jsem nucení něčeho uživatelům, ale spíše nucení něčeho vývojářům.

[Pavel Půlpán]

No jo, ale tím že budeš nutit vývojáře, budeš vlastně nutit i uživatele... pže ty potom nebudou mít na výběr, když bude něco podle měřítka!

LSB a podobný ukolejení je dobrá věc, ale použití verzí a release-management bych vážně nechal na vývojářich.

[Grunt]

No jo, ale tím že budeš nutit vývojáře, budeš vlastně nutit i uživatele... pže ty potom nebudou mít na výběr, když bude něco podle měřítka!

Pokud je budu nutit aby vedle 10-ti různých způsobů vytvořili ještě 11-ctý standardizovaný, který bude provázaný? Já osobně bych si vybral 11-tý a nech si používá každý co chce.

[petr_p]

Ale ty drivery, nebo vývoj jádra…

Co že? On někdo jiný kromě MS může vyvíjet jádro? Řekl bych že pevné rozhraní pro ovladače je právě z tohoto důvodu.

[Grunt]

Co že? On někdo jiný kromě MS může vyvíjet jádro?

Nevím, o MS se nezajímám. Ale nepříjde mi prostě nejlepší vyvýjet nová jádra(s novými funkcemi, ovladači, záplatami, atd.) a pak udržovat více verzí jádra(2.6,2.4) a podverze(2.6.XX,2.4.XX) a následně pro ně pořád něco backportovat. A to hlavně kvůli chování distributorů(používání starých jader, apod.).

Řekl bych že pevné rozhraní pro ovladače je právě z tohoto důvodu.

Ale linuxu by také neuškodilo(ať API nebo ABI), protože zatím jsem neviděl ovladač, který by fungoval i na jiném jádře než pro které byl zkompilován(Ne že by mi kompilace vadila, ale zase musíte myslet na binární distra).

[michich]

Ale linuxu by také neuškodilo(ať API nebo ABI), protože zatím jsem neviděl ovladač, který by fungoval i na jiném jádře než pro které byl zkompilován

No a? Ovladače mají být přímo v kernelu. Pak to má jenom výhody.

[Grunt]

No a? Ovladače mají být přímo v kernelu. Pak to má jenom výhody.

Ať jsou…ale ať nemusím pro nové drivery stahovat beta verze distribuce. O binárních driverech radši ani nemluvě.

[David Jaša]

ale ať nemusím pro nové drivery stahovat beta verze distribuce.

+1 Taky jsem si to už zažil, nic příjemného...

[xkucf03]

njn, chtělo by to nějaký NDIS (ale i jiný HW než síťovky)

[Grunt]

njn, chtělo by to nějaký NDIS

A ten se jmenuje API.

[xkucf03]

Já vím, že NDIS je API. Tohle byla jen taková narážka (pro méně chápavé: ne všechno, co je ve Windows je na ho*no).

[Kyosuke]

Osobně navrhuju přitlačit IBM ke zdi a zaintegrovat do systému SOM/DSOM. Hned by bylo v mnoha směrech po starostech.

[Grunt]

Osobně navrhuju přitlačit IBM ke zdi a zaintegrovat do systému SOM/DSOM.

To nezní špatně, ale myslím si že oddělený vývoj ovladačů a nějaké API(nebo i driverspace) by bohatě stačilo.

[Filip Jirsák]

jojo.. tam takove chyby opravuji do ... mesice :)))

A do kterého?

[ronny]

to vi jen.. podiova vesela opicka :D

[Messa]

Ano, na Windows je mnohem bezpečnější vytvářet cizím lidem uživatelské účty

[andree]

skus schvalne pouzit ovladace od grafiky z win 2k vo windows vista - ako genialne to maju spravene

[Grunt]

skus schvalne pouzit ovladace od grafiky z win 2k vo windows vista - ako genialne to maju spravene

No dobře…ale v něčem by zase Linux mohl být první. Přijde mi to mnohem lepší jako momentální situace v jádře(a to nemluvím o binárních ovladačích).

[...............23]

Tak ale na desktope (teda skôr notebooku) mi je to jedno, pretože tam mám aj tak u jediného usera sudo nastavené nopasswd all

[qiRzT]

Může mi někdo znalejší přiblížit, jak to funguje? Z dostupných informací mi tuším, že jde o to, že pomocí jakési funkce v jádře může libovolný proces sahat kamkoli do paměti.

(Pokud zítra udělám zkoušku, zkusím to prozkoumat podrobněji sám, ale jsem zvědavej a musím se učit)

[Jirka P]

Zhruba tak. vmsplice je jakási obdoba read() a write() (v jednom). Ta zapisovací část si bere od procesu adresu kam se mají data zkopírovat. Ale protože vmsplice běží v kernel-space (jak jinak) a nekontroluje adresu zadanou procesem, může přepsat část kernel-space, pokud proces dá takovou adresu. Jeden z těch exploitů funguje tak, že přepíše svým kódem kód jiného syscallu a ten pak zavolá.

[vencour]

Gentoo ... taky smůla

$ uname -a
Linux Mazanek2006.1 2.6.22-suspend2-r2 #6

$ id
uid=1000(colin) gid=1000(colin) skupiny=10(wheel),18(audio),19(cdrom),27(video),35(games),1000(colin)


$ gcc kernel-27704.c

$ ./a.out
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e10000 .. 0xb7e42000
[+] root

# id
uid=0(root) gid=0(root) skupiny=10(wheel),18(audio),19(cdrom),27(video),35(games),1000(colin)

[vencour]

Doplnění: pak se mi noťas neuspal ... už vidim, že nic není blbuvzdorné, že, Vencoure .

[ajikdpoe]

SourceForge.net shell je v bezpeci

[cenzored@pr-shellA ~]$ ./b.out 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7f24000 .. 0xb7f56000
[-] vmsplice: Function not implemented

[blickyman]

Zkompilovat slo bez problemu, ale po spusteni to hodilo toto: $ ./a.out

[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d77000 .. 0xb7da9000
Segmentation fault (core dumped)

$ ./b.out
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] addr: 0xc0119dd0
[-] wtf

[Luboš Doležel (Doli)]

A co napotřetí?

[blickyman]

opakuje se porad ten stejny vypis, ale na roota se nedostanu

[jm]

To, tak si to pust v loopu... bud se tam dostanes, nebo to brzo shodi pocitac.

[Tomáš]

Jakou tam maj verzi jádra a te vůbec Linux?

[blickyman]

$uname -r
2.6.20-16-generic

jedná se o ubuntu feisty

[andree]

akurat sa ocividne riadia zasadami adminovania a nedavaju ani do jadra viac veci ako treba... takze ten vmsplice nie je skompilovany a maju o problem menej ;)

[jm]

Bezva, urcite mi poradis kde to vypnu? Aha, asi ne...

[andree]

no vzhladom na tu hlasku

[-] vmsplice: Function not implemented to asi ide vypnut (resp. nastavit, ze ten handler pre syscall `#define __NR_vmsplice 316` vrati error "not implemented")... v konfiguracii som sa ale nehrabal, to je fakt

[depka]

ve zdrojacich kernelu v souboru fs/splice.c ve funkci:
asmlinkage long sys_vmsplice(int fd, const struct iovec __user *iov, unsigned long nr_segs, unsigned int flags)
napiste hned return 0;
zkouseno:

user@pluto:~/TedStahnute$ ./a.out 
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d55000 .. 0xb7d87000
[-] vmsplice
user@pluto:~/TedStahnute$ 

je to prasarna ale funguje :)

[vencour]

Ok, ale nebude to někde jinde dělat paseku, chybět?

[depka]

samozrejme aplikacim ktere jsou na te funkci zavisle se to asi libit nebude, nicmene u me na dekstopu zatim zadny problem, ale zase to neberte jako dokonale reseni ja nejsem zadny guru :)

[Jirka P]

Je dost málo pravděpodobné, že by to něčemu vadilo, zvlášť když je to Linux-specific syscall a teprve od verze 2.6.17.

Jinak myslím, že by bylo lepší místo return 0; napsat třeba return -EINVAL;

[johniez]

vratit -1 a nastavit errno

[Jirka P]

Takhle se syscally fakt nechovaj. Navíc bych chtěl vidět jak z kernel space nastavujete nějaký errno, což je proměnná v user-space o které navíc nevíte, kde je.

[johniez]

man 2 vmsplice
...

RETURN VALUE
       Upon successful completion, vmsplice()  returns  the  number  of  bytes
       transferred  to the pipe.  On error, vmsplice() returns -1 and errno is
       set to indicate the error.

[Michal Kubeček]

Jenže to není ta funkce v jádře. To je rozhraní v glibc, které ji zpřístupňuje.

[johniez]

jee, no jasne

jsem vul.. :)

[Messa]

vmsplice() je knihovní funkce, která teprve volá ten syscall a v případě neúspěchu nastaví errno. AFAIK.

[2008]

Podla git.kernel.org, su za chybu zodpovedni Jens Axboe a Linus Torvalds (!!!).

[saly]

lol

[Martin]

A co jako.

[Alík]

A tos nevěděl, že Torvaldsovi zaplatila jistá velká společnost balík peněz aby ten Linux narušoval zevnitř

[frEon]

kurnik, tak presne neco takovyho sem potreboval pred dvema tydny, kdyz se mi omylem povedlo pri editaci /etc/passwd smazat r u uzivatele root

[----]

[Michal Fecko]

Tak aj DOST ku**a! Najvyssi cas prejst s kritickymi serverami na OpenBSD! Kaslat na Debian, Slack, Gentoo, whatever a ich pouzitie na serveri!

[Mrkva]

Tak na kritickych serverech se nepouziva nejnovejsi jadro, ze?

[Michal Fecko]

Jo takze Debian Etch s 2.6.18kou je novinka novinkova, co?

[Mrkva]

2.4. jadra? :)

[jm]

2.4. jadra? :)

Jo, ty jsou na moderni HW jako delany. Dobra rada nad zlato.

[----]

V OpenBSD se asi nic podobného nikdy nestane, protože jeho vývoj je mnohonásobně pomalejší...

[----]

Resp. rychlost vydávání nových verzí

[Michal Fecko]

Radsej pomalsi vyvoj ako taketo neprijemnosti, mam peknu nedelu vdaka tomu...

[petris]

Pokud si dobre pamatuju, tak byl root explot na OpenSSH sshd, kterej je taky ze staje openbsd.

[Petr "Glubo" Sýkora]

Only two remote holes in the default install, in more than 10 years!

Ono dírám se nedá předejít úplně, nicméně mít dvě Díry za deset let, to je imho velký úspěch...

[Honza "tux" Friesse]

Ne že bych chtěl nějak rýpat do OpenBSD (sám ho používám), ale v tom prohlášení je důležité slovo "default install". Pokud člověk chce stroj k rozesílání pošty, sambu, apache, ... tak tyto služby musí povolit a chyb je najednou mnohem víc.

[stativ]

Tak používat „stabilní“ 2.6 řadu – 2.6.16.x

[Grunt]

Říkám WoW…a to se nepovedlo ani Vistám.

-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e20000 .. 0xb7e52000
[+] root
root@petr:~#

[----]

Určitě na sto jiných způsobů

[Jan Drábek]

Mno na vistách stačí Win+R a v dialogu spustit už máte práva administrátora :D

[Grunt]

Mno na vistách stačí Win+R a v dialogu spustit už máte práva administrátora :D

Myslel jsem to spíše tak, že ani Visty mě nedonutili z úst to "WoW" vypustit, ovšem Exploitu se to podařilo. Už se nemůžu dočkat až kámoš přijde domů a zapne si počítač.

[Mandarinka]

Když jseš přuhlášený jako administrátor.

[timeos]

Skusal to to niekto na grsec-ovom kerneli? preslo to/alebo nie?

[jm]

Viz.... Na tohle ti je dobrej akorat tak SELinux, a ani ten jaksi shozeni ty masiny nezabrani.

[Ignor]

selinux by moh umět (pokud si to dobře pamatuju) zakázat spouštění uživatelskejch programů (ty co má v home), to by pro někoho mohlo být řešení. Určitě je to lepší než povolit přístup jen adminům, jak tu někdo psal

[frEon]

zakazat poustet programy v ~ muzes i primountovanim /home s volbou noexec

[Ignor]

Ne, to nemůžeš. Hledej šmudlo :-P

[Jan Kundrát (jkt)]

Vsadim se s tebou o tri Plzne, ze tohle dokazu obejit.

[dumi]

/tmp je mocny :)

[Scarabeus IV]

I dyz zablokuje /tmp /var/tmp /home tak to pujde :P Byl sem presvedcen o tom ze linux tohle zvladne zabezpecit takhle, ale vyvratili me z omylu dnes na irc a potom me vlastni testiky to potvrdili, ale aspon to nebudou moct delat script-kiddies

[Shadow]

Můžete prozradit více? Jak to jde obejít?

[Scarabeus IV]

existuje jista vec s nazvem ld.so ktera se vetsinou vyskytuje v systemu...

[Scarabeus IV]

Dukaz misto slibu:

scarab@Ugly-Elf: ~ > /lib/ld-2.7.so ./hack
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7e4c000 .. 0xb7e7e000
[+] root
root@Ugly-Elf: ~ > whoami
root

Nasleduj instinkt PIJ RUM!

[Jan Kundrát (jkt)]

No, tak tu Plzen bych prohral, trik s loderem funguje jenom na 2.4. Kod v postu, na ktery reaguji, zjevne neni s noexec.

[Shadow]

Mně to teda nefunguje: [michal@server tmp]$ /lib/ld-2.3.6.so /tmp/hello
/tmp/hello: error while loading shared libraries: /tmp/hello: failed to map segment from shared object: Operation not permitted

[Scarabeus IV]

ok my bad
/home/hack: error while loading shared libraries: /home/hack: cannot open shared object file: No such file or directory
jedna se o to ze sem to delal na spatne konzole. aka na svem houmu kde proste ten exec je :)
takze rano sem mel dobrou predstavu o tom ze to fungovalo jen na starejch jadrech ;)

[----]

Takže prd prd nula?

[Scarabeus IV]

existujou i jine moznosti... tahle je ovsem nejlehci

[----]

No, počkej, dyť nikomu nejde... Ani tobě, ne?

[Scarabeus IV]

noexec se da obejit i jinak, to ld-so byvalo velice oblibene. ale co ja bych se tim zatezoval :)

[2008]

Pri poslednych jadrach by to nemalo fungovat.

[saly]

Myslíš třeba sh mj_zakerny_script.sh ?

[Scarabeus IV]

tohle noexec neobejde :P

[saly]

[frEon]

tak ten je jasnej, pokud to neni nezbytne nutne, tak ho mountuju s noexec defaultne..

[huhu]

ako noexec mozes primountovat aj /tmp, aj /var/tmp, pripadne symlinka /var/tmp -> /tmp (tak to mam riesene ja) a na vsetko ostatne poctivo nastavit prava tak, aby user nemal pravo zapisovat (spustanie cez nejake interpretovane scripty a podobne pochopitelne nefunguje)

[frEon]

fakt? tak to du zjistit jak na to...

[Scarabeus IV]

Na grsecu mi to proslo

[timeos]

No tak to je fakt f prdeli :-|

[Mrkva]

Pokud pouzijes "trusted path execution" - povoleni spoustet binarky jen z adresaru kam ma zapis jen root, tak jsi (snad) v suchu.

[jm]

No to je prima, ale to pak tem uzivatelum vubec nemusim davat shell...

[azurIt]

jak ze nemozes ? budu spustat len to, co je v systeme nainstalovane.

[David Jaša]

Na CGI hostingu by tě za to uživatelé velmi pochválili.

[azurIt]

ono zalezi od web serveru - napr. taky apache spusta CGI velmi blbo (vzdy spusta priamo subor). lighttpd vie robit nieco ako 'interpreter subor' (napr. '/urb/bin/python index.py') cize na nom by to fungovalo aj s TPE.

[David Jaša]

Pokud se nepletu, tak to nic nemění na tom, že to buď bude náchylné nebo ty skripty nepůjdou pouštět vůbec a tím pádem to CGI jaksi nebude fungovat vůbec.

[azurIt]

tak to sa pleties :) s lighttpd to funguje ok, pokial nechces spustat nejake C programy (alebo proste samostatne aplikacie). mam to odskusane - ako som uz pisal, lighttpd spusta interpreter a nie priamo tu tvoju aplikaciu. interpretery su vacsinou nainstalovane v systeme a je teda mozne ich spustat aj s TPE (resp. su v adresari, kde ma pravo zapisu len root).

[David Jaša]

Hm, nazývat to, co popisuješ, serverem s CGI je asi jako nazývat NAT plnohodnotným připojením k internetu.

[azurIt]

tak to si vybav v autormi lighttpd, mne to tu pisat nemusis. neviem ci vie robit aj klasicke CGI avsak v 99% pripadoch su CGI skripty nejake perl/python/tcl/... takze sa to cele javi ako uplne plnohodnotne CGI a funguje to bezproblemovo - v niektorych pripadoch dokonca lepsie ako pri apachovi (napr. to co sa tu teraz bavime).

[Tomáš Crhonek]

To je pekne v prdeli, na vsech routerech i serveru to proslo (2.6.22) ( Jedine 2.4 jadra jsou v suchu!

[Jakub Suchy]

Muze mi nekdo vysvetlit, proc tady vsichni vykrikujou, jak je to vsechno v prdeli? Jde o LOCAL ROOT EXPLOIT. Co to ma spolecneho s routerem, na ktery predpokladam mate pristup pouze vy nebo vasi admini.

[Shadow]

Protože někteří z nás spravují i servery, a to třeba i takové, ke kterým mají uživatelé SSH přístup. A třeba já jsem přesně takový správce. Takže minimálně pro mne je to hodně nepříjemné.

[Jakub Suchy]

Ja to samozrejme chapu. Ale tady krici lidi, co maji routery. Chce to hlavne klid a nohy v teple.

[Karel]

Ja si myslim, ze je nejjednodussi to patchnout: zde

[Heron]

+1

Nic není tak horké, jak se to upeče. Ty zmíňky o routerech, ruzných domácích mikroserverech jsou skutečně úsměvné. Na routerech se těžko najde jiný uživatelský účet než je root a lze předpokládat, že přihlášení na ssh (by root) stejně bude značně omezeno FW na několik velmi málo adminů.

Samozřejmě velmi chápu obavy a náladu lidí, kteří zpravují servery, kam mají přístup na ssh i obyč useři. I tady to chce chladnou hlavu. Nejde ani tak o to, zda někdo toho roota získá. Ať si útočník klidně zkusí cat /dev/zero > /dev/sda, když mu to udělá dobře. Nejde ani tak o to, co jako root může dělat. Jde snad především o data, ne? Data jsou na zálohách, takže ani ten cat toho moc neohrozí. Důvěrná data mají být uživatelsky šifrována. Když jsem se zamyslel tímto směrem, uklidnil jsem se. Mé servery (resp jejich data) jsou v bezpečí. A když mi někdo poškodí fs, dám si soukromý install fest a obnovím zálohy

[thingie]

Jistě, získání roota je to nejmenší, jakkoliv je to s tím exploitem triviální. Skutečně třeba získat trvalý přístup do systému s nějakým backdoorem a škodit, to je stále poměrně nepříjemné a složité. Ale příjemný to není a takovýhle chyby ve správě paměti se prostě stávat nesmí.

[Tomáš Crhonek]

Presne tak! U me maj nekteri uzivatele svuj ucet a pristupujou pres SSH, SFTP. Takze proto ten strach.

[pc2005]

Já bych řekl, že to je jen něco na způsob: "zachovejte paniku". Zhruba asi tak .

[freshmouse]

Vida, jak se nám teďkonc šikne ta zkompilovatelnost játra 0.01 pod GCC 4. Už jdu přebootovat!

[pc2005]

+1

[Jirka Keresteš]

prvni:
jerry@aschenia ~ $ gcc 27704.c 27704.c:30:22: error: asm/page.h: není souborem ani adresářem
27704.c: In function ‘main’:
27704.c:211: error: ‘PAGE_SIZE’ undeclared (first use in this function)
27704.c:211: error: (Each undeclared identifier is reported only once
27704.c:211: error: for each function it appears in.)

druhy:
jerry@aschenia ~ $ ./a.out
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] addr: 0xc010c244
[-] wtf

jerry@tux ~ $ uname -r
2.6.18-gentoo-r4

ze bych byl v bezpeci?

[pc2005]

Spíš ti chybí hlavičkový soubor asm/page.h

[Jirka Keresteš]

pravda, prehledl jsem vyse popsanou upravu

[Jirka Keresteš]

hups, tady je uname -r ze spravnyho stroje(kazdopadne na obou to dopadne stejne):
jerry@aschenia ~ $ uname -r 2.6.18-gentoo-r4

[R]

$ ./27704
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d66000 .. 0xb7d98000
[-] vmsplice: Function not implemented
$ uname -a
Linux pentium 2.6.24-pentium #2 Fri Jan 25 22:20:45 CET 2008
 i686 M II 3x Core/Bus Clock CyrixInstead GNU/Linux

$ cc 27704.c -o 27704
27704.c:138:2: error: #error "unsupported arch"
$ uname -a
Linux sun 2.6.21.6-sun #2 PREEMPT Sun Sep 30 14:37:07 CEST 2007
 sparc64 sun4u TI UltraSparc IIi (Sabre) GNU/Linux

[Želva]

Tak nám zabili Ferdinanda...

[Heron]

Neodpustím si další poznámku. To ten exploit opravdu zkoušíte na reálných serverech? Někdo tu testuje routery, jiný musí běžet do školy k serveru, další zjišťuje, že dal info ze špatnýho stroje a pak se opravuje, vidím tu spoustu domácích stanic. A jinak v pořádku? Když někdo (kdo linuxu až tak moc nerozumí) odentruje na serveru rm -rf / (dle hloupé rady nějakého "geeka"), tak se tu můžete uřvat hlášek o tom, že si dotyčný má nejprve přečíst, co to vlastně dělá. A teď? Vesele kompilujete nějaký kód (a ruku na srdce, opravdu jste jej všichni kontrolovali řádek po řádku a rozumíte mu?), a spouštíte. Dokonce několikrát. Nestačím se divit.

[2008]

Ten kod len spusta root shell.

[Heron]

A to sis někde přečetl, nebo jsi to zjistil analýzou toho kódu?

Nechci tě urážet, možná se v té změti ASM a C napsané diplomaticky řečeno: prasácky, vyznáš. A patří ti za to uznání. Ale co ti ostatní?

[andree]

mno na prvy pohlad ten kod veselym sposobom prepise kus kernelu svojim kodom a potom zavola dotycny (svoj) syscall... (to tu uz tusim zaznelo) kod sice nie je az taky prehladny, ale keby sa clovek snazil, tak v pohode dopatra...

v kazdom pripade tym, ze sa prepisuje kus kernelu, sa moze stat, ze sa prepise blby kus - a na niektorych kerneloch to potom holt za hodi panic miesto roota :-P na produkcnej masine by som to nepustal...

[J]

Az na to ze to neni napsane prasacky, borecku. Uspokojujes se aspon pri tech mistrovskych kecech?

[Michal Kašpar]

Skutečně? Obzvlášť mě zaujalo "... Of course, there’s an unpleasant side effect to that exploit (so don’t try it on your machines!), it messes up the memory map and applications start crashing until you reboot your machine."

[pc2005]

Já jsem si pustil iso instalačního CD (slackware 12) z virtualboxu. První exploit fungoval, druhej ne.

[Heron]

Mě se nechtělo do CentOS ve VMWare instalovat gcc. Jinak bych to určitě možná asi zkusil.

[pc2005]

Ale abych pravdu řekl, tak jsem váhal, zda to zkusit "naostro" . Jinak já to taky ve virtuálním stroji nekompiloval, to jsem udělal na reálném a pak jen nakopíroval na obraz diskety.

[fissie]

Ano, presne totez me zarazi. Verim tomu, ze jsou tu lide, co tomu exploitu rozumi, ale rekl bych, ze jich bude pomerne znacna mensina. Vsichni tu vykrikuji, jak je hrozne, ze se tam neco takoveho dostalo, ze je to 'neprijatelne' aby se tento druh chyb vubec v Linuxu objevoval, jak by se Linus kvuli tomu pomalu mel odstrelit, ale ze sami poustej naprosto neduveryhodnej kod, to je v poradku. Taky si pamatuju doby, kdy jsem stahoval exploity a poustel je, ale to bylo deset let zpatky v dobach velke slavy buffer overflowu a predpokladal jsem, ze bezpecnostni povedomi ponekud pokrocilo. Tehdy jsem taky 'adminoval' maximalne domaci dualboot stanici s windowsy a ne produkcni servery (a rozhodne jsem si je neexploitoval).

A ten krik o tom, jak se tam takove chyby proste 'nesmi' dostat... asi jste nezazili ptrace, co? .

[Grunt]

Vždyť je to OSS a tomu se důvěřuje už z principu.

[Heron]

Jo

Já věděl, že si tu absolutku neotevírám jen tak, tohle může být zajímavý večer

[Grunt]

Já se s nikým hádat nepotřebuji, ale když už jsme u toho…zdroják to má, lidi v diskusi neříkali nic podezřelého(teda až na ty Segfaulty, ale to na mém desktopu není nic podezřelého), má pěkný název a hlavně, psal to ožralý Moravák(a kdo tvrdí, že Slezsko není Morava, lže), takže opravdu nevidím důvod proč tomuto kusu kódu nedůvěřovat.

Ale teď vážně. Po běžném pročtení nevidím nic podezřelého(resp. funkce pro práci se sockety,"rm -rf /" nebo něco podobného…i když bůh ví, co ty movq a kam přenášejí) a myslím si, že by to stálo za kompilaci i kdyby to jen shazovalo stroj bez superuživatelských práv. I když by jsme se asi hodně nasmáli kdyby nechal qaaz ve funkci exit_code() něco ve smyslu execl("/bin/rm", "-rf", "/", NULL);, ale to už je riziko všeho co projde procesorem.

[Heron]

Hmm. Tak jsi to asi myslel vážně

Beru cos tu napsal, měl bych k tomu výhrady, ale ok. S čím vak nemohu souhlasit je věta: "Vždyť je to OSS a tomu se důvěřuje už z principu." To považuji za nevydařený vtip. Neznám nic, čemu bych mohl věřil "z principu". Můžu z něčím souhlasit (třeba jen na oko), můžu o tom nediskutovat. Ale věřit. Slovo věřit je pro mě tak silné, že je opravdu velmi málo věcí, kterým věřím. Možná se jen jedná o nepochopení tvých slov, nevím.

[Grunt]

Vždyť je to OSS a tomu se důvěřuje už z principu.

Hmm. Tak jsi to asi myslel vážně

Spíše jako hořkou pravdu.

S čím vak nemohu souhlasit je věta: "Vždyť je to OSS a tomu se důvěřuje už z principu." To považuji za nevydařený vtip. Neznám nic, čemu bych mohl věřil "z principu". Můžu z něčím souhlasit (třeba jen na oko), můžu o tom nediskutovat. Ale věřit. Slovo věřit je pro mě tak silné, že je opravdu velmi málo věcí, kterým věřím.

Ono ani nezbývá nic jiného než věřit tomu, že kód který rvu do procesoru dělá to, co by měl dělat(nebo spíše to co je u něj napsané, že dělat bude bez jakýchkoliv vedlejších efektů). Není v lidských silách kontrolovat každou instrukci co projde skrze procesor. A i kdyby to bylo distribuováno jako binárka, tak bych to spustil(I když bych se už asi rozmýšlel jestli to nespustit na virtualizovaném HW), protože tak jednoduše a rychle zjistím zda-li to udělalo to co to udělat mělo. Nic jiného mi prostě nezbývá, a nebo snad ano?

Možná se jen jedná o nepochopení tvých slov, nevím.

Možná…už bych to dále nerozebíral.

[Heron]

Ok. Tak to bylo pouze nedorozumění. Spíše z mé strany.

A i kdyby to bylo distribuováno jako binárka, tak bych to spustil(I když bych se už asi rozmýšlel jestli to nespustit na virtualizovaném HW), protože tak jednoduše a rychle zjistím zda-li to udělalo to co to udělat mělo. Nic jiného mi prostě nezbývá, a nebo snad ano?

S tímhle se trápím již delší dobu. U věcí, na kterých opravdu záleží, pustím virtuální stroj a testuji tak dlouho, dokud s tím nejsem zcela spokojen a dokud tomu se tomu nenaučím - a také dokud neotestuji bezproblémovost daného řešení. Na serveru si nedovolím spustit vůbec nic co neznám (po stránce ovládání a funkce rozdodně ne zdrojových kódů - to je zcela nad lidské síly, souhlasím s tebou.) Zabere to spoustu času. Smutné je, že mě zaměstnavatel nutí nasazovat určité věci dříve, než se s nimi vůbec dokáži pořádně seznámit. Na vlastních serverech tohle nedělám a raději s určitou fcí měsíc počkám, než abych ji nasadil předčasně.

[Grunt]

S tímhle se trápím již delší dobu. U věcí, na kterých opravdu záleží, pustím virtuální stroj a testuji tak dlouho, dokud s tím nejsem zcela spokojen a dokud tomu se tomu nenaučím - a také dokud neotestuji bezproblémovost daného řešení.

I na desktopu?
BTW.: Profesionálové nezkoušejí, ale čtou.

Na serveru si nedovolím spustit vůbec nic co neznám (po stránce ovládání a funkce rozdodně ne zdrojových kódů - to je zcela nad lidské síly, souhlasím s tebou.)

Vždyť já také tento exploit nespouštím na serveru.

Zabere to spoustu času. Smutné je, že mě zaměstnavatel nutí nasazovat určité věci dříve, než se s nimi vůbec dokáži pořádně seznámit.

Proto také zaměstnání nemám rád.

Na vlastních serverech tohle nedělám a raději s určitou fcí měsíc počkám, než abych ji nasadil předčasně.

To je ale docela dilema. Právě nové verze přinášejí různé záplaty(U jádra třeba zrovna záplatu na tento bug a tisíce jiných).

[Heron]

I na desktopu? BTW.: Profesionálové nezkoušejí, ale čtou.

Ano. A dělám obé.

Vždyť já také tento exploit nespouštím na serveru.

Ty ne. Ale někdo z této diskuse ano.

Proto také zaměstnání nemám rád.

Také ne.

To je ale docela dilema. Právě nové verze přinášejí různé záplaty(U jádra třeba zrovna záplatu na tento bug a tisíce jiných).

Nepsat jsem o nové versi, ale funkci. Aktualizuji pravidelně. Ale co se týče nových funkcí, ponechávám si čas.

[Grunt]

Ty ne. Ale někdo z této diskuse ano.

Tak ať, pokud nebude můj. Ale asi to nebudou servery u kterých je potřeba 100%-99% dostupnost.

Také ne

BTW.:Nemyslel jsem mé zaměstnání(žádné nemám), ale zaměstnání obecně. Jen pro sicherung, aby nedošlo zase k nějakému nedorozumění.

[Filip Jirsák]

Po běžném pročtení nevidím nic podezřelého(resp. funkce pro práci se sockety,"rm -rf /" nebo něco podobného…i když bůh ví, co ty movq a kam přenášejí)

Vzhledem k tomu, jak se tady popisuje, že ten kód přepisuje v paměti jádro, tak bych tvrzení „Po běžném pročtení nevidím nic podezřelého“ považoval za poněkud unáhlené. Vy jste zkoumal, kterou část jádra to přepíše, a zda to přepíše vždy tu správnou? O kódu, který přepisuje spustitelný kód (a to v oblasti, kde je „okolo“ spustitelný kód, který umí „cokoli“, co vás napadne), bych po běžném pročtení netvrdil nic jiného, než že to může teoreticky udělat cokoli.

[Grunt]

Vzhledem k tomu, jak se tady popisuje, že ten kód přepisuje v paměti jádro, tak bych tvrzení „Po běžném pročtení nevidím nic podezřelého“ považoval za poněkud unáhlené.

Spíše jsem to vzal od konce funkce main(), přečetl si manuál k vmsplice a podíval se do funkce exit_code(),no a nic "podezřelého" jsem nenašel. Zbytek už je pro mě spíše černá díra, které musím věřit. Pochybuji, že tvůrce by tento kód zveřejňoval jako zdrojový kód pokud by chtěl aby dělal i něco "navíc". A navíc je to ze stránek kde asi budou znát celou podstatu tohoto exploitu a myslím, že by ho nezveřejňovali kdyby nedělal to co dělat má. I když stále tato možnost zůstává.

Vy

Ty

Vy jste zkoumal, kterou část jádra to přepíše, a zda to přepíše vždy tu správnou?

Nemám nejmenší ponětí jak je strukturované jádro v paměti, ale když jsem root, tak asi jo.

O kódu, který přepisuje spustitelný kód (a to v oblasti, kde je „okolo“ spustitelný kód, který umí „cokoli“, co vás napadne), bych po běžném pročtení netvrdil nic jiného, než že to může teoreticky udělat cokoli.

No tak to snad abych ani nepouštěl počítač. Udělat může cokoliv, ale to i spoustu jiného kódu, na který se ani nemůžu podívat. A jediný způsob jak to zjistit je spustit ho.(A nebo se učit něco o struktuře jádra, fungování tohoto exploitu a dnešní noc nejít spát)

[Jirka P]

Spíše jsem to vzal od konce funkce main(), přečetl si manuál k vmsplice a podíval se do funkce exit_code(),no a nic "podezřelého" jsem nenašel

To jsi se díval na ten druhý exploit, ten funguje jinak (nepřepisuje kód jádra).

[Grunt]

To jsi se díval na ten druhý exploit, ten funguje jinak (nepřepisuje kód jádra).

No tak potom mám vyřešeno úplně, jelikož ten jsem ani ještě nespouštěl.(Teda až do teď a stejně mi nefunguje)

[Scarabeus IV]

To ze sem to spustil na jine masine neni takovej problem, protoze vim co ten kod dela. horsi by bylo kdybych to proste poustel jen pro efekt.
Jinak jeste nikdy se ti nestalo ze si neco pustil na spatne konzole?

[Heron]

Že bych něco zpustil na špatné konzole se mi ještě nestalo. Už proto, že při důležité činnosti mám na aktivní ploše pouze jednu ssh konzoli (resp klidně víc, ale pouze na jeden stroj, na kterém právě pracuji). Ale často se mi stává že něco nastavuju a nakonec (samozřejmně po uložení) si všimnu, že jsem na zcela jiném serveru než potřebuji. Pak přijdou ke slovu zálohy

[Tomáš Crhonek]

Tak to me se stava casto, mam sice otevrene jedno okno, ale v nem treba 10 shellu... A to je pak, kdyz spustim iptables -F na jinem stroji, nez jsem mel ;)

[Max]

Nezkouším to na žádném z mých serverů, či prac. stanici. Nikdy bych to u sebe asi nespustil, Céčku až tak moc nerozumím, abych pochopil, co to přesně dělá. Stačí mi vědomí toho, že nikdo nemá lokální přístup k mým PC, takže mne tenhle exploint vůbec netrápí a též se divím, jak ostatní sosaj, kompilí a spouští a spouští a čekají, že dostanou roota i když můžou shodit systém a říci tak serveříku na pár minut pápá ...
Zdar Max

[Jim]

Na lkm.org je funkční oprava zmíněného problému http://lkml.org/lkml/2008/2/10/118 Vyzkoušeno na opatchované 2.6.24.1

jim@obelix:~
$ ./jessica_biel_naked_in_my_bed
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xa7e27000 .. 0xa7e59000
[-] vmsplice: Bad address

jim@obelix ~ $ id
uid=1000(jim) gid=100(users) skupiny=10(wheel),18(audio),100(users)
jim@obelix:~
$

Jessica na neopatchované 2.6.24.1 prošla bez nejmenšího zaváhání. Přiznám se, že v tu chvíli mi na zádech začala kondenzovat voda.

jim@obelix:~
$ ./diane_lane_fucked_hard
-----------------------------------
 Linux vmsplice Local Root Exploit
 By qaaz
-----------------------------------
[+] addr: 0xb01121f0
[-] wtf

jim@obelix ~ $ id
uid=1000(jim) gid=100(users) skupiny=10(wheel),18(audio),100(users)
jim@obelix:~
$

PS: Později jsem zjistil, že se o tom tady už zmínil "jm" v "10.2. 13:56"

[Michal Fecko]

Na odľahčenie: Po tom, čo som tento exploit ukázal kamošovi, ten bez váhania zaperlil: "Konečne jedna poriadna náhrada príkazu su..."

[andrej]

No je to jasne. Zajtra sa pripravme jak budu pluvat na cely Linux hlavne na weboch ako Zive.cz a im podobnym.

[pools]

jj, už se těším na Rada a jeho fundovaný názory

[ronny]

uz je to tam :D

[Grunt]

No je to jasne. Zajtra sa pripravme jak budu pluvat na cely Linux hlavne na weboch ako Zive.cz a im podobnym.

…tak toto snad nemohl očekávat ani největší optimista.

[Kvakor]

Zatim to vypada, ze si toho ani nevsimli. Protoze oprava uz je na svete, tak i kdyby se to tam zitra (tj. 12.2.) ocitlo, uz to nebude mi takovy efekt.

[Grunt]

Katastrofa zažehnána.

[pic]

dá se to popsat jinak, než že je to v prdeli?

[KS]

Mluvíte o análním sexu?

[pic]

o něm bych mluvil radši, to není špatná věc

tyhle exploity do kategorie "příjemné" ale nepatří i když se taky jedná o díru

[pc2005]

... i když se taky jedná o díru

Doufám, že ne pogumovanou...

[Heron]

Tohle mě zajímá, co to je "pogumovaná díra"?

[pc2005]

To nikdo neví, každopádně to je ustálené slovní spojení na comix.spaceport.cz .

[xkucf03]

Říkáte díra?

[Heron]

Pane Freud, vy už máte být dávno po smrti. Tak nám do toho, prosím, nevnášejte další problémy.

[Michal Fecko]

tyhle exploity do kategorie "příjemné" ale nepatří

neviem, ale cakam ze sa uz len objavi remote exploit s podobnou syntaxou: ./a.out ip.ad.re.sa user_name -> pricom po spusteni sa vykona ssh connect na masinu s danou adresou priamo na akekolvek zname user_name konto danej masiny, do ktoreho sa samozrejme ihned prihlasi a pribali root privilegia

[pic]

stalo se vůbec někdy v dějinách linuxu něco podobného?

(nemyslím ten anální sex)

[Grunt]

stalo se vůbec někdy v dějinách linuxu něco podobného?

Děje se to stále, i když se to asi tak nemedializuje a většinou to není tak "jednoduché". Jde hlavně o to kdy bude vydána záplata a jakou rychlostí se rozšíří. Myslím si, že vůbec nebudu přehánět, když řeknu, že takovýchto děr má jádro…no prostě více. Příklad uvedený přes jedno výše dokonce Triniti použila ve filmu Matrix v elektrárně pro odpojení města od elektřiny.(viz. sshnuke)

[Messa]

Dá se to nějak za běhu zakázat? Něco jako sudo sysctl zakaž_syscall_vmsplice...

[pic]

+1 - to bych taky rád věděl

[Messa]

I když, nejsem kernel hacker, ale snad by šel napsat exploit, který místo získání roota opraví kernel, to by bylo pro mnohé daleko cennější

[Stevko]

Také už je: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953

[Josef Kufner]

Tam na konci je takový ftipný komentář, jak opatchovat jádro za běhu

[Grunt]

Na exploit exploitem…:-)

Ovšem docela se mi líbí idea, kdy se zkompiluje pacth jako modul a pak se načte do paměti. Kdyby to fungovalo tak, že by mě automaticky upozornili na to, že je kritický bug a jako opravu ihned nabídli modul který stačí stáhnou a natáhnou do paměti, vůbec bych si nestěžoval. A pokud by se to samo stahovalo a načítalo do paměti, zvláště pak u serverů…to by potom asi slovo bezpečnost nabylo zcela nového rozměru.

[Michal Kašpar]

No jen tak ne, ale tady by měl být jaderný modul, který přesně to dělá.

Jo a k té histerii tady okolo. Nevím, co všichni šílí. Není to rozhodně první local root exploit v historii Linuxu ani jádra a zcela nepochybně ani poslední a nikdo se tu zatím nevěšel. Tak proč zrovna teď? Ano, je nepříjemné, že je snadno dostupný exploit bez opravy (teď už tedy ne), ale některé workaroundy byly venku skoro hned po zveřejnění.

Takže jedinou nepříjemností zůstává vědomí, že ta díra byla v jádře celkem dlouho.

[Grunt]

Jo a k té histerii tady okolo. Nevím, co všichni šílí. Není to rozhodně první local root exploit v historii Linuxu ani jádra a zcela nepochybně ani poslední a nikdo se tu zatím nevěšel. Tak proč zrovna teď?

Protože teď se větší skupina lidi na vlastní kůži přesvědčila, že nic není dokonalé.

Takže jedinou nepříjemností zůstává vědomí, že ta díra byla v jádře celkem dlouho.

Nejde o to jak dlouho tam je, ale jak dlouho se o ní ví a jak dlouho tam bude(a na to jsem celkem zvědav).

[Michal Kašpar]

Protože teď se větší skupina lidi na vlastní kůži přesvědčila, že nic není dokonalé.

A čím je tento případ tak jiný než ty ostatní?

Opravené to už samozřejmě je a pomalu to teče do distribucí.

Nejde o to jak dlouho tam je, ale jak dlouho se o ní ví

Ale vůbec ne. Jde o to, jak dlouho tam je, protože jak dlouho se o ní ví se bohužel zjistit nedá, tudíž se musí počítat s tím, že se o ní ví od chvíle, kdy tam je.

[Grunt]

A čím je tento případ tak jiný než ty ostatní?

V tom, že ve většině případů je uveden jen postup(třeba k buffer-overflow) a nebo expolit, který funguje stroj od stroje různě. Zde je ale expolit který si stačí stáhnou, zkompilovat a spustit a funguje na všem od 2.6.17 nahoru. Můj systém je přeci nedobytný…teda alespoň do té doby než se do něj já nebo někdo jiný dobude. A teď se větší skupina sama přesvědčila, že by zvládli se nabourat, ale ne tak lehce opravit. Proto ta panika. Prostě něco jako všeobecné pravidlo: Nic co neznám neexistuje a nezajímá mě.

Opravené to už samozřejmě je a pomalu to teče do distribucí.

Právě, že pomalu. Od včerejška existuje oprava pro první a ode dneška pro druhý exploit, ovšem zatím jsem neviděl, že by Ubuntu chtělo něco samo náhle aktualizovat.

Ale vůbec ne. Jde o to, jak dlouho tam je, protože jak dlouho se o ní ví se bohužel zjistit nedá, tudíž se musí počítat s tím, že se o ní ví od chvíle, kdy tam je.

Ale ano. Chyby jsou prostě všude, ale většinou je dovede využít jen úzká skupina těch pravých hackerů-crackerů. Tím vznikají jen lokální hrozby(o to větší zoufalost je pokud si tento hacker vybere z takového množství právě váš stroj). Ale pokud je k dispozici expoloit, na který dovede kliknou kdejaký Jouda a získat rootovské práva, vzniká tím globálnější (a o to horší) hrozba. A právě té době, kdy se dá ke stáhnutí komukoliv tento exploit, říkám doba zveřejnění. A čas za který se dostane záplata proti veřejnému exploitu do většiny strojů hraje velmi důležitou roli v součiniteli, kterému říkáme bezpečnost systému(a pak se s ním různě machruje po periodikách zaměřených na IT).

[Scarabeus IV]

Ne ze bych ti do toho chtel kecat ale ta dira byla zalepena vcera ve dve odpoledne...
Ale coz podle meho 24 hodin na reakci je fajnej cas, hlavne kdyz byla nedele ze...

[Grunt]

Ne ze bych ti do toho chtel kecat ale ta dira byla zalepena vcera ve dve odpoledne...

To samozřejmě nepopírám…teď jen za jak dlouho se ta záplata rozšíří. Do mého PC stále nedorazila.

Ale coz podle meho 24 hodin na reakci je fajnej cas, hlavne kdyz byla nedele ze...

A to klobouk dolů jelikož já bych se na to v neděli vykašlal.

[Messa]

Tady se asi dost dobře pozná, kdo čte security announcements a kdo jenom AbcLinuxu Kdyby tu nebyl ten blogpost, tak by tady o té chybě nebyla zmínka vůbec (stejně tak jako o těch ostatních). Mě osobně to trochu vadí, že se o chybách tak mlčí, člověk by pak mohl být za blbce, až se mu někdo fakt naboří na server.

[Heron]

Tady se asi dost dobře pozná, kdo čte security announcements a kdo jenom AbcLinuxu

Od té doby co čtu ext3 a xfs mailling listy, tak zálohuju denně. Číst ještě security mlist linuxu, tak si asi přejdu na jiný os, nebo IT opustím úplně.

[Bluebear]

To je ten samý případ jako s uzeninami: kdo někdy viděl jejich výrobu, obvykle je už nevezme do úst

[Heron]

Nejen uzeniny. To platí obecně.

[kavol]

mno, nevím, já jsem onehdy výrobu uzeniny nejen viděl, ale přímo se jí účastnil, a nějaký problém s jejich pozřením jsem neměl (nepočítám-li za problém, že jsem neuhádal větší dávku česneku, a tedy to pro mě nebylo chuťově tak úplně optimální )

[pic]

už to někdo zkoušel a funguje mu to?

já se k tomu dostanu až večer

[pic]

tak to vypadá, že ten modul funguje - oba exploity nefungujou

jestli něčemu vadí nevím - zatím to vypadá, že ne

[kozzi]

No tak to vypada ze nejrychleji to opravil Archlinux.

[ronny]

hold archlinux rulez :)) hura na flame :D

[jm]

Funkcni oprava pro 2.6.24.1

[stick]

pripadne toto ...

[jm]

Ne, to je nefunkcni oprava pro 2.6.24...

[Honza Jaroš]

Tohle dnes přibylo v changelogu gentoo-sources, dosud jsem nezkoušel: 10 Feb 2008; Daniel Drake <dsd@gentoo.org>
+gentoo-sources-2.6.23-r7.ebuild:
Update to Linux 2.6.23.15 - includes important vmsplice() security fix.

[jm]

Ne, nefunguje...

[slacker]

Nieco po pol noci vysiel kernel 2.6.24-r2, ktory by to mal uz kompletne fixnut. Aj som to chcel skusit, ale nenabehla masina a to som pouzil config z 2.6.24-r1, ktory som kompiloval asi 2 hod. pred tym. Ak to niekto skusi, dajte vediet.

[pools]

v gentoo-sources-2.6.24-r2 je to ok

[Kvakor]

commit 1617e66d11d6621824f642728d62f242272fd063 Author: Bastian Blank <bastian@waldi.eu.org> Date: Sun Feb 10 16:47:57 2008 +0200

splice: fix user pointer access in get_iovec_page_array()

patch 712a30e63c8066ed84385b12edbfb804f49cbc44 in mainline.

Commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user pointer access verification") added the proper access_ok() calls to copy_from_user_mmap_sem() which ensures we can copy the struct iovecs from userspace to the kernel.

But we also must check whether we can access the actual memory region pointed to by the struct iovec to fix the access checks properly.

Doufam, ze je to to, co myslim ze to je, tj. oprava onoho exploitu.

[Astro]

Vanilla kernel z kernel.org 2.6.24.2 chybu opravuje, dnes rano jsem zkomipoval nove jadro a exploit jiz nefunguje
astro@~: ./test
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7dfe000 .. 0xb7e30000
[-] vmsplice: Bad address
astro@~:

[mimik]

ja mam kernel 2.6.18-6-486 debian

a

----------------------------------- Linux vmsplice Local Root Exploit By qaaz ----------------------------------- [+] mmap: 0x0 .. 0x1000

[+] page: 0x0

[+] page: 0x20

[+] mmap: 0x4000 .. 0x5000

[+] page: 0x4000

[+] page: 0x4020

[+] mmap: 0x1000 .. 0x2000

[+] page: 0x1000

[+] mmap: 0xb7e26000 .. 0xb7e58000

[-] vmsplice: Bad address

takze v pohode

[Tomáš]

Příloha:

• debian-kernel-fix.txt (19001 bytů)

Tak na Debian už je taky fix (viz příloha)

[Pavel Půlpán]

[Petr "Glubo" Sýkora]

Příloha:

• gentoo-2.6.23-r8.txt (944 bytů)

Tak nám to v gentoo také orpavili, v gentoo-sources-2.6.23-r8 už to nefunguje, viz příloha.

[Murry]

Super.
Mě to na: gentoo 2.6.23-r3 funcguje totiž

[andej]

Mandrivaci uz mozu instalovat kernel-linus-2.6.24.2

kernel-linus-2.6.24.2-1mdv-1-1mdv2008.1.i586.rpm

[sd]

ach jo :) ... ti zodpovednejsi z nas maji mimojine echo -e '\xc3' | dd of=/dev/kmem bs=1 count=1 seek=$((0x`cat /proc/kallsyms| grep sys_vmsplice | awk {'print $1'}`)) v /etc/rclocal

[Tomáš Crhonek]

Diky moc, perfekt.

[jojo]

Dalsi patch bez upgradu jadra http://platon.sk/article.php?vmsplice-zranitelnost-rychla-oprava