Bezpečnostní díra v jádře

[root@fc8-x86~]# cat /proc/sys/vm/­mmap_min_addr
65536

Fedora 11, to same…

nesro@nesro-desktop:~$ cat /proc/sys/vm/­mmap_min_addr
0

[root@Archie ~]# uname -sr
Linux 2.6.31-ARCH
[root@Archie ~]# pacman -Q | grep kernel26
kernel26 2.6.31.5–1
kernel26-firmware 2.6.31–1
[root@Archie ~]# cat /proc/sys/vm/­mmap_min_addr
4096

:)

Mandriva (cooker, 2.6.31, x86_64) ma „prekvapive“ taky 4096 ;-)

mohu tu hodnotu zmeni v tom /proc… ? aniz by se stalo neco katastrofalniho?

Můžeš, ale (prý) pak přestanou fungovat některé emulátory, jako dosemu.

Podle me to neni pravda, viz prispevky podemnou, co znamena ta hodnota.
I kdyz kdo pouziva dnes DOSemu ;-)) kdyz zde mame KVM a dosbox

openSUSE Factory:

> cat /proc/sys/vm/­mmap_min_addr
65536

… by tato práva …
… na většině systémů majících …
Už je mi vlastně jedno o čem zpráva je. Jakmile vidím ‚Adam Štrauch‘ jdu dělat korektury.

Díky, opraveno.

Co je to za číslo? Co bych tam měl dát za číslo? Zatím jsem tam dal hodnotu RAM v MB

Je to minimální adresa, na kterou lze z uživatelského prostoru něco namapovat, v bytech. Jako workaround na dereferenci NULL v jádře by tam měl být malý násobek velikosti stránky (=4096 na i386)

Tak se mi stalo něco horšího… něco ten soubor přepisuje při restartu a háže tam 0.

Vždy tam napíšu 4096, buď vypnu nebo restartuju a po přihlášení do konzole je tam 0. Jelikož mi systém nabíhá do konzole, ze které pak spouštím GDM, tak to přepisuje něco co se nastaruje během nabíhání nebo při přihlášení.

Lze nějak zjistit, který proces k tomu souboru přistupoval?

tak to jsem zase něco vymyslel… :-( nj, když je to v sysfs, tak to asi po restartu bude opravdu zpátky.

A nebo doplnte nasledujici do souboru /etc/sysctl.conf (pokud ho mate ve Vasi distribuci):

vm.mmap_min_addr = 4096

…především to totiž není žádný soubor, ale virtuální filesystém jádra, takže hodnoty se po restartu neuchovávají. Buď to tam pište vždy po startu, nebo si překompilujte patchnutý kernel s již nastavenou hodnotou.

Neni tohle nahodou ta dira, ktera je i s exploitem znama z poloviny srpna (http://blog.cr0.org/…-due-to.html) a byla jiz v te dobe diskutovana, tusim i tady na rootu?

Reseni tehdy pokud vim spocivalo v nastaveni vm.mmap_min_addr = 4096 coz by odpovidalo popsane chybe. Nebo se jedna o neco noveho se stejnym resenim?

Ne, je to jiná chyba (obávám se, že dereferencí NULL bude v jádře víc).

Jinak „řešení“ s vm.mmap_min_addr = 4096 je spíš workaround.

Tento problem x86 architektury je v OpenBSD uz davno opravenej…

problem x86 architektury? co je tam specificke pre x86?

IMHO mají jiné architektury lépe vyřešenou ochranu paměti, takže není potřeba zbytečně všem aplikacím mapovat kusy jádra do paměti – včetně nulové stránky.

Ale tohle je nedorozumění – nulová stránka v žádném případě není součástí jádra. Dále, jádro se do paměťového prostoru aplikací mapuje i na jiných architekturách – ne proto, aby aplikace mohla přistupovat k jádru, ale naopak, aby jádro mohlo přistupovat k paměti aplikace. Ne, že by to nešlo jinak (i na 32bitu), viz např. 4G/4G patch, ale je to takový opruz, že se vám na to programátoři víte co… Například na MIPSu je rozdělení paměti dokonce zadrátované v architektuře.

Zabránit, aby jádro spouštělo kód z userspace, by šlo i na x86, ale zas to má svá ale.

No, to, co jsem řekl určitě není úplně přesné, nejsem expert, proto je tam to IMHO. Zkrátka některé jiné architektury jinak mapují paměť a tak k této chybě nemusí dojít.

Ano, 8 měsíců po vydání Linuxu 2.6.23 (2007/09) s podporou mmap_min_addr vyšlo OpenBSD 4.3 (2008/05) se zvýšenou hodnotou VM_MIN_ADDRESS. Naštěstí jsou oba systémy tak děravé, že šaškárny s NULLem nejsou vůbec potřeba. Ještě něco nám povíš?

± 8 :)

Doporucuji napred se vzdelavat, testovat a pak odpovidat. Pak se nestane, ze ze sebe udelate osla ;-)

http://marc.info/?…

Linux mel toto jen jako option a ne jako opravu, takze default bylo nula. I kdyz to ted ma nastavane, tak staci stupidne napsany program (Wine), Pulseaudio (Ubuntu 8.04, 8.10 a kdovi kde jeste) a je to zpatky na nule a navic nektere distra to maji porad na nule. Takze to, ze Linus zacne tvrdit, ze ma nejakou opravu a pritom staci nainstalovat nejaky program aby se to znova zmenilo zpatky na nulu nepovazuji lide co tomu rozumi za opravu ;-) Oprava je neco takoveho, ze uz se s predchozim problemem nesetkate, coz neni v pripade Linuxu pravda. Navic ti co tu chybu zkoumali zjistili, ze RedHat (Fedora,…) se sice tvari jako ze tu volby ma zapnutou, ale skutecnost je uplne jina ;-) OpenBSD zkoumalo skoro dva roky jak tu opravu udelat tak, aby to bylo pouzitelne, bezpecne a neovlivnilo to ostatni programy. Timhle se Linux nezabyval a tezko nekdy bude, protoze si nemuze dovolit to opravit poradne.

> Doporucuji napred se vzdelavat, testovat a pak odpovidat.

Stalo se. Proto jsem napsal to, co jsem napsal a myslel jsem tím právě a jen to.

> Pak se nestane, ze ze sebe udelate osla ;-)

Tak jako vy dalším odstavcem.

# cat /proc/sys/vm/­mmap_min_addr
cat: /proc/sys/vm/­mmap_min_addr: No such file or directory

tak nevim… ;-)

To je ta horsi varianta, pak se tenhle workaround neda pouzit, ale dira tam asi stale je exploitovatelna.

Výsledek na Debian 5.0 (Lenny) s vlastně sestavovaným jadrem:

hulka@Axson:~$ uname -srm
Linux 2.6.29.6 x86_64
hulka@Axson:~$ cat /proc/sys/vm/­mmap_min_addr
0
hulka@Axson:~$

Poslední dobou se chyby v linuxovém jádře objevují jak houby po dešti. Začínám být rozpačitý … je to dobře nebo špatně?

Otazka zni jestli se objevuji, nebo jsou tam pridavane.
Jestli je to stara chyba, ktera se objevi, tak je to myslim dobre, i kdyz ty updaty kernelu jsou docela otravne.
Jestli tam pridavaji nove a nove, tak je to spatne. :) Alespon pro mne, vzhledem k tomu ze aktualne umi kernel vse co potrebuji, takze mne osobne dalsi vyvoj nechybi. :P

# cat /proc/sys/vm/­mmap_min_addr
65536

To uz je tak trosku dost stara zpravicka ne ? Exploit na tohle uz jsem si prohlizel minuly tyden.

Jde jen o politováníhodné opomenutí několika package mainteinerů. Je to o tom, že když člověk rozbalí zdrojáky nového kernelu, dělá make oldconfig a ono se ho to ptá na něco, o čem nemá ani páru, tak by neměl odentrovat defaultní 0, ale třísknout do otazníku a přečíst si, že:

CONFIG_DEFAUL­T_MMAP_MIN_AD­DR:

This is the portion of low virtual memory which should be protected
from userspace allocation. Keeping a user from writing to low pages
can help reduce the impact of kernel NULL pointer bugs.

For most ia64, ppc64 and x86 users with lots of address space
a value of 65536 is reasonable and should cause no problems.
On arm and other archs it should not be higher than 32768.
Programs which use vm86 functionality or have some need to map
this low address space will need CAP_SYS_RAWIO or disable this
protection by setting the value to 0.

This value can be changed after boot using the
/proc/sys/vm/­mmap_min_addr tunable.
…

Každý normální člověk, tam po přečtení tohodle přece na ia64/ppc64/x86 dá buď 65536 nebo číslo, které mu z nějakého důvodu příjde ještě lepší.

42?⠀

docela by me zajimalo odkud se vzala ta informace o /proc/sys/vm/­mmap_min_addr na tom linkovanem blogu.

sedim tady na dosud nepatchnutem gentoo-cku s 2.6.30-r6 a ze zabavy jsem zkusil stahnout prvni exploit pro CVE-2009–3547 na ktery jsem na webu narazil a nestih jsem se divit:

$ cat /proc/sys/vm/­mmap_min_addr
4096
$ whoami
domuize
$ gcc ImpelDown-2.6.31only.c -o imp
$ ./imp
$ whoami
root

je to prosim nekdo schopny reprodukovat?
pavel

negativne, na slacku 13 nejde spustit

http://marc.info/?…

Jak to souvisí se zprávičkou?