Kernel

Bővebben a 2.2, 2.4, 2.6 kerneleket érintő hibáról

Címkék

Marcelo Tosatti ma sebtében két kernel release-t is kiadott. Az egyik a 2.4.24-rc1 volt, majd néhány perccel később a 2.4.24-rc1-et kiadta változatlanul stabil 2.4.24-ként. Ennek az oka az, hogy olyan biztonsági hibát találtak a 2.2, 2.4 és 2.6 kernel kódjában, amelyet kihasználva root jogokhoz juthat a rosszindulatú támadó.

Van proof of concept exploit, és működik is. Kötelező olvasmány (hiba leírása) ->Synopsis: Linux kernel do_mremap local privilege escalation vulnerability

Product: Linux kernel

Version: 2.2, 2.4 and 2.6 series

Vendor: http://www.kernel.org/

URL: http://isec.pl/vulnerabilities/isec-0013-mremap.txt

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0985

Author: Paul Starzetz ,

Wojciech Purczynski

Date: January 5, 2004


Issue:

======

A critical security vulnerability has been found in the Linux kernel

memory management code in mremap(2) system call due to incorrect bound

checks.


Details:

========

The mremap system call provides functionality of resizing (shrinking or

growing) as well as moving across process's addressable space of existing

virtual memory areas (VMAs) or any of its parts.

A typical VMA covers at least one memory page (which is exactly 4kB on

the i386 architecture). An incorrect bound check discovered inside the

do_mremap() kernel code performing remapping of a virtual memory area

may lead to creation of a virtual memory area of 0 bytes length.

The problem bases on the general mremap flaw that remapping of 2 pages

from inside a VMA creates a memory hole of only one page in length but

an additional VMA of two pages. In the case of a zero sized remapping

request no VMA hole is created but an additional VMA descriptor of 0

bytes in length is created.

Such a malicious virtual memory area may disrupt the operation of other

parts of the kernel memory management subroutines finally leading to

unexpected behavior.

A typical process's memory layout showing invalid VMA created with

mremap system call:

08048000-0804c000 r-xp 00000000 03:05 959142 /tmp/test

0804c000-0804d000 rw-p 00003000 03:05 959142 /tmp/test

0804d000-0804e000 rwxp 00000000 00:00 0

40000000-40014000 r-xp 00000000 03:05 1544523 /lib/ld-2.3.2.so

40014000-40015000 rw-p 00013000 03:05 1544523 /lib/ld-2.3.2.so

40015000-40016000 rw-p 00000000 00:00 0

4002c000-40158000 r-xp 00000000 03:05 1544529 /lib/libc.so.6

40158000-4015d000 rw-p 0012b000 03:05 1544529 /lib/libc.so.6

4015d000-4015f000 rw-p 00000000 00:00 0

[*] 60000000-60000000 rwxp 00000000 00:00 0

bfffe000-c0000000 rwxp fffff000 00:00 0

The broken VMA in the above example has been marked with a [*].


Impact:

=======

Since no special privileges are required to use the mremap(2) system

call any process may misuse its unexpected behavior to disrupt the kernel

memory management subsystem. Proper exploitation of this vulnerability may

lead to local privilege escalation including execution of arbitrary code

with kernel level access. Proof-of-concept exploit code has been created

and successfully tested giving UID 0 shell on vulnerable systems.

The exploitability of the discovered vulnerability is possible, although

not a trivial one. We have identified at least two different attack

vectors for the 2.4 kernel series. All users are encouraged to patch all

vulnerable systems as soon as appropriate vendor patches are released.


Credits:

========

Paul Starzetz has identified the vulnerability and

performed further research.


Disclaimer:

===========

This document and all the information it contains are provided "as is",

for educational purposes only, without warranty of any kind, whether

express or implied.

The authors reserve the right not to be responsible for the topicality,

correctness, completeness or quality of the information provided in

this document. Liability claims regarding damage caused by the use of

any information provided, including any kind of information which is

incomplete or incorrect, will therefore be rejected.

Marcelo Tosatti: Linux 2.4.24-rc1

Címkék

Marcelo kiadta a Linux 2.4.24-rc1 kernelpatchet. Ez a patch egy bugfix kiadás. Emellett két biztonsági hibát is javít, így a frissítés ERŐSEN JAVASOLT!Az egyik biztonsági javítás Andrea Arcengeli nevéhez fűződik. A mremap() rosszindulatú használója extra privilégumokhoz juthat. A másik biztonsági a hiba a /dev/rtc-ben van, amely a kernel memória egyes részeit teszi elérhetővé a a privilégium nélküli felhasználóknak.

Letölthető patch-2.4.24-rc1.bz2.

Változások listája Marcelo levelében itt.

A legfrissebb kernel letöltése rsync és cvs segítségével

Címkék

Petri Koistinen egy olyan scriptet készített, amely segítségével a fejlesztők (vagy bárki) letölthetik a legfrissebb Linux kernel forrásokat a saját gépükre rsync és CVS felhasználásával.A script segítségével a 2.4-es a 2.5-ös és a 2.6-os kernelek forrásait tölthetjük le, majd a későbbiekben már csak szinkronizálnunk kell a forrásainkat az rsync segítségével.

A scriptet megtalálod Petri levelében itt.

PaX patch a 2.6-os kernelhez

Címkék

A PaX Team-nek köszönhetően elérhető egy kísérleti PaX biztonsági patch a 2.6-os (2.6.0) Linux kernelhez. A patch a 2.4.23-as kernelhez készült folt előre portolt verziója, amely jelenleg i386 platformon működik biztosan, a többi platformon valószínűleg le sem fordul.

A PaX patch használatával számos puffer túlcsordulásra építő támadásnak állhat ellen rendszerünk. Kipróbáltam a patchet a stabil 2.6.0-ás kernelen.



A tapasztalatok:A kernel simán lefordult, az összes PaX opciót engedélyeztem a ``menuconfig''-ban. Bebootolva a kernelt a fixen belefordított hálózati kártya inicializálása előtt kaptam egy ``general protection fault''-ot, de a kernel felállt, és elindította a rendszert. Lefuttattam a paxtest-0.9.5 tesztet. Eredménye:

Executable anonymous mapping : Killed

Executable bss : Killed

Executable data : Killed

Executable heap : Killed

Executable stack : Killed

Executable anonymous mapping (mprotect) : Killed

Executable bss (mprotect) : Killed

Executable data (mprotect) : Killed

Executable heap (mprotect) : Killed

Executable shared library bss (mprotect) : Killed

Executable shared library data (mprotect): Killed

Executable stack (mprotect) : Killed

Anonymous mapping randomisation test : 16 bits (guessed)

Heap randomisation test (ET_EXEC) : 13 bits (guessed)

Heap randomisation test (ET_DYN) : 25 bits (guessed)

Main executable randomisation (ET_EXEC) : 16 bits (guessed)

Main executable randomisation (ET_DYN) : 17 bits (guessed)

Shared library randomisation test : 16 bits (guessed)

Stack randomisation test (SEGMEXEC) : 23 bits (guessed)

Stack randomisation test (PAGEEXEC) : 24 bits (guessed)

Return to function (strcpy) : Vulnerable

Return to function (strcpy, RANDEXEC) : Return to function (memcpy) : Vulnerable

Return to function (memcpy, RANDEXEC) : Killed

Executable shared library bss : Killed

Executable shared library data : Killed

Writable text segments : Killed

A patch a kezdeti ``GPF''-től eltekintve nem okozott semmilyen negatív változást a kernelben (eddig). A PaX alkalmazása után néhány alkalmazás nem fut. Erről a kernel menuconfig help-je tájékozatat is minket. A legemlítésreméltóbb programok, amelyek nem indulnak el: az Xfree86 4.x verziója, a Java viruális gép és a Wine. A patch szerintem nem is desktop gépeken kap nagyobb hangsúlyt, hanem szerveren, ahol esetleg több rosszindulatú helyi felhasználóval kell számolnunk. A patchelt kernellel futott a MySQL 4.x, az Apache legújabb verziója, működött a PHP-ra írt weboldal, ment a postfix, és az amavisd-new is. Mindez Debian Sarge operációs rendszeren. Hosszabb távú tapasztalatok nincsenek, hiszen a patch 3 napja jelent meg. Tervezem egy teszt szerver felállítását, amely lokális hálón nagy terhelésnek van kitéve.

A szerver üzemeltetés szempontjából érdekes lehet még az, hogy mekkora a ``overhead''-je (overhead ebben az esetben = a patch működéséből adódó lassulás) van a patchnek. A dokumentáció szerint i386 és ppc környezetben számolnunk kell az ``overhead''-del. Erre vonatkozólag még nem végeztem méréseket. Az alpha, ia64, parisc, sparc, sparc64 és x86_64 platformokon nem kell overhead-del számolnunk.

A patch tesztelésre letölthető:

http://pax.grsecurity.net/pax-linux-2.6.0-200312302245.patch

A PaX mögött álló elgondolásról bővebben itt olvashatsz. A patchelt kernel teszteléséhez használható a paxtest-0.9.5 tesztprogram. A patchelt kernelen file alapon tudjuk a PaX jelzőket állítani. Ehhez a chpax programra van szükségünk.

Jó szórakozást!

Marcelo Tosatti: Linux 2.4.24-pre3

Címkék

A mai nap a kernel kiadások napja. Marcelo kiadta a 2.4.24-pre3 kernelt. Többek közt PPC32/SPARC frissítést, i2c kódtisztítást, LVM frissítést, új WAN drivert tartalmaz.

Letölthető innen.

Változások listája Marcelo levelében itt.

Andrew Morton: Linux 2.6.1-rc1-mm1

Címkék

Alig adta ki Linus a 2.6.1-rc1 kernelt, AKPM máris postázta a 2.6.1-rc1-mm1 patchet (a listán hibásan 2.6.0-rc1-mm1-ként jelent meg). A patch néhány új funkció mellett a fő kernelfával történő szinkronizációkat tartalmazza.A patch letölthető:

ftp://ftp.kernel.org/.../akpm/patches/2.6/2.6.1-rc1/2.6.1-rc1-mm1/

Változások listája AKPM levelében itt.

Linus Torvalds: Linux 2.6.1-rc1

Címkék

Linus kiadta a 2.6.1-rc1 patchet. A foltba az eddig várólistán levő anyagok kerültek. Ahogy Linus írja, most egy újabb nyugalmas időszak kezdődik (azaz új dolgok nem kerülnek be a kernel forrásba), amíg ki nem derült, hogy a végleges 2.6.1 rendben van-e. A legtöbb új dolog már régóta jelen van Andrew Morton -mm fájában, és stabilnak tekinthető.

A patch letölthető linux-2.6.1-rc1.tar.bz2

Változások listája Linus levelében itt.

netconsole: hogyan debugoljunk hálózaton keresztül

Címkék

Debugolni néha kell. Hogy miért?

Biztos mindenki került már olyan helyzetbe, hogy kernelfordítás után valami nem volt teljesen OK. Vagy nem volt a monitoron kép, mert elfelejtettük valamelyik konzol komponenst belefordítani a kernelbe, vagy a rendszer nem találta a / filerendszert, mert elfelejtettük az IDE, SCSI vagy más lemezvezérlő driverét, vagy egyszerűen csak rossz filerendszert állítottunk be a kernel konfigurációs részében. Sorolhatnám még a felmerülő hibákat, de a lényeg az, ha valamilyen oknál fogva gépünket nem tudjuk legalább a ``single'' módig (init 1) bebootolni (ehhez ugye az kell, hogy az init-et elérjük, vagy legalább egy shell-t (bash, sh, stb.) tudjunk init-ként használni), akkor nagyon nehéz a debugolás. A boot üzenetek egy korszerű gépen gyorsan lefutnak a képernyőn, így tényleg nagyon kell figyelni, hogy az ember a megfelelő pillanatban leolvashassa a hibaüzenetet. Másik bosszantó dolog, ha kernel panic-ot kapunk mindjárt a bootolásnál, és azt szeretnénk szeretnénk debugolni. Nem hiszem, hogy bárki nekiállna egy oops üzenetet papírral és ceruzával leírni... Akkor mégis hogyan rögzítsük az ilyen félig bootolt gép üzeneteit?

Andrew Morton: Linux 2.6.0-mm2

Címkék

AKPM kiadta a stabil 2.6.0-ás második -mm patchét.

Adaptec SCSI frissítések, az ieee1394 csapat frissítései és számos más javítás (pl. azon CD-ROM-mal kapcsolatos problémák javítása, amelyek a -mm1-ben jöttek elő) kerültek bele.