Archiv verlassen und diese Seite im Standarddesign anzeigen : Schocking: local exploit 2.6.17-2.6.24.1
Holla, da haben die uns mit ihrer turbo-Kopier-Option splice ja ein schönes Ei gelegt:
http://it.slashdot.org/it/08/02/10/2011257.shtml
Dagegen hilft Patch (getestet mit Fedora 8) :
--- linux.orig/fs/splice.c 2008-02-11 11:41:16.000000000 +0100
+++ linux/fs/splice.c 2008-02-11 11:42:05.000000000 +0100
@@ -1289,6 +1289,9 @@ static int get_iovec_page_array(const st
if (unlikely(!base))
break;
+ if (unlikely(!access_ok(VERIFY_READ, base, len)))
+ break;
+
/*
* Get this base offset and number of pages, then map
* in the user pages.
Gruß Aqualung
Rain_maker
11.02.08, 14:22
*Würgaround* ohne selbst einen neuen Kernel bauen zu müssen.
http://www.pc-forum24.de/sonstige-news/8398-pro-linux-linux-kernel-2-6-local-root-exploit.html
Zumindest bis zum nächsten Kernelupdate brauchbar.
Wie das für $DISTRIBUTION einzubinden ist, damit es vor dem Login von $USER ausgeführt werden kann, können dann ja User anderer Distributionen hier beitragen.
//Edit:
Die beschriebenen Stabilitätsprobleme hier
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953
kann ich bisher nicht nachvollziehen, aber trotzdem "use at your own risk".
//Edit2:
Die Lösung über das Kernelmodul novmsplice.ko dürfte vorzuziehen sein.
Greetz,
RM
derRichard
11.02.08, 18:51
hallo!
es gibt auch eine lösung, wo nicht ganz übelst im kernel herumgebastelt werden muss.
man kann den syscall mit systemtap abstellen.
stap -v -p4 -k -m stap_novmsplice -g stap_novmsplice.stp
staprun -L ./stap_novmsplice.ko (muss aus /tmp/... herkopiert werden)
stap_novmsplice.stp:
#!/usr/bin/stap
probe kernel.function("sys_vmsplice") {
printf("blocking vmsplice syscall by pid/uid: %i %i", pid(), uid())
$nr_segs = 0
}
man braucht die pakete kernel-devel, kernel-debuginfo und systemtap.
hth,
//richard
Fröhliches Testen:
Der Exploit bringt den Kernelspeicher durcheinander, und das führt
dazu, daß das System i.d.R. nach einer Weile sowieso abstürzt und
kann auch dazu führen, daß z.B. kaputte Daten auf die Platte
geschrieben werden und ähnliches. Und ja nicht den sogenannten Hotfix
"disable-vmsplice-if-exploitable.c" verwenden, denn der probiert den
Exploit auch erst aus und hat die selben Folgen!
Besser grsecurity verwenden - das hilft:
http://grsecurity.net/pipermail/grsecurity/2008-February/000885.html
mfg
cane
derRichard
12.02.08, 16:46
hallo!
würde ich gerne, leider gibt es schon länger kein release mehr von grsecurity, das man auch nur ansatzweise verwenden kann.
//richard
...oder Kernel patchen und ausnamhsweise doch mal rebooten...? Ich könnte damit zumindest besser schlafen, als mit seltsamen Workarounds, die den Exploits selbst nutzen.
derRichard
12.02.08, 16:50
hi!
naja, sofern man für alle systeme den kernel selber pflegen will...
//richard
Mittlerweile sollten ja alle Distributionen Updates haben...bei dem Presseecho sollte man nicht so lange mit dem Update warten.
derRichard
12.02.08, 17:05
glaubst du die distributoren warten absichtlich?
das testen der updates braucht leider immer etwas.
lieber habe ich eine bekannte lücke, mit der ich umgehen kann als kaputte updates.
//richard
Mittlerweile sollten ja alle Distributionen Updates haben...bei dem Presseecho sollte man nicht so lange mit dem Update warten.
Zumindest alle, bei denen es nicht zwangslaeufig auf Stabilitaet ankommt. RHEL war z.B. bis gestern noch nicht gepatcht.
'cuda
http://www.centos.org/modules/newbb/viewtopic.php?topic_id=12639&forum=42
RHEL und Centos seid gestern Abend bzw. Heute.
Rain_maker
13.02.08, 10:51
Zumindest alle, bei denen es nicht zwangslaeufig auf Stabilitaet ankommt.
Eben.
SuSE hatte die Patches auch erst gestern nachmittag/abend "offiziell" über das online-Update heraus gebracht, aber wer es besonders eilig hatte oder testen wollte, der konnte sich den/die (waren ja 10.2 und 10.3 betroffen) Patch(es) schon einen Tag vorher aus dem Test-Repository herunterladen.
Verlinken werd ich die aber nicht, sonst glauben ein paar Newbies, sie könnten sich das als "immer das Neuste und Geilste"-Repo in die Paketerwaltung klemmen (und dann wird rumgeplärrt "Wähää my SUSÄ funzt nimma rischdigggg!11111ELF").
Wer genug $AHNUNG hat, um sinnvoll mit den Patches aus dem obigen Repo umzugehen, der findet sie auch so, wer nicht mal das Repo von alleine findet, der kann eh nichts Sinnvolles damit anfangen.
Greetz,
RM
Zumindest alle, bei denen es nicht zwangslaeufig auf Stabilitaet ankommt. RHEL war z.B. bis gestern noch nicht gepatcht.
'cuda
Sicher, das ist natürlich immer eine Trade-off-Entscheidung. Zumindest testing-Pakete sollten die meisten schnell anbieten und dann muß jeder Admin für sich entscheiden, ob er es einspielt oder nicht.
RHEL hat ja auch ältere Kernel mit "tausenden" Patches. Wenn die dann zwei Tage länger brauchen, ist das immer noch sehr schnell. Der "Upstream"-Patch ist hier ja nicht mehr so einfach anwendbar.
Sicher, das ist natürlich immer eine Trade-off-Entscheidung. Zumindest testing-Pakete sollten die meisten schnell anbieten und dann muß jeder Admin für sich entscheiden, ob er es einspielt oder nicht.
Nope, der Admin der sowas einspielt, gehört gefeuert.
Flightbase
13.02.08, 12:26
ja, das problem ist nur, dass alle brauchbaren admins warten, bis andere das getestet haben.
unterm strich heißt das aber, dass es nur von nicht-brauchbaren admins getestet wurde ;P
greets, Nik
oder von welchen, die sich das auf einem ded. Testsystem anschauen?
Flightbase
13.02.08, 12:30
ach soooo ;]
macht man doch?.... oder...?
*unsicherwerd*
Flightbase
13.02.08, 12:38
du hättest mein erstes posting hier nicht so ernst nehmen sollen ^^
<SEUFZ>
macht man doch?.... oder...?
*unsicherwerd*
Ich wünschte man würde das... bei uns (XP - System) geh ich jedes mal die Wände hoch wenn ungetestet Patches per Skript über Nacht eingespielt werden.. zumal die mir oft meine MS Office Einstellungen "zurücksetzen" ..... hilft nix.. passiert jedes mal wieder... daher ist meine Suse Installation auf meinem Frickel-PC zuhause stabiler als die XP Installation mit der ich im Job arbeiten muss... obwohl _der_ von "Profis" administriert wird .....
Seufz....
Wie könnte ich ein Posting von einem Admin nicht ernst nehmen?
Aber mal ernsthaft: Wenn ich mir überlege: Es gibt in irgendwelchen Beta-Repos einen Patch für ein dringendes Problem - bis ich den bei mir reingebastelt habe und auf sämtliche Nebenwirkungen getestet habe und dann den Roll-Out evtl. durch QM und sonstige Dinge boxen darf - bis dahin hat vermutlich der Distributor meines Vertrauens schon einen offiziellen Patch gemacht.
Ob und wie dringend ein solcher Patch für einen selbst ist - hängt vermutlich sehr von den jeweiligen Umständen ab. Ich kann mir vorstellen, dass ein Admin eines Unix-Pools an einer Hochschule etwas nervöser reagiert hat als ein Oracle-Admin, der seine User eh nur über 1521 auf die Kiste lässt...
Jeder Laden, der sich ein bisschen mit IT beschäftigt wird früher oder später ein Testbed aufziehen. Schon allein um Probleme, durch ungetestete Produkte und Installationen zu vermeiden. Immerhin ist IT nicht operatives Geschäft sondern Mittel zum Zweck. IT hat zu funktionieren. Je nach Abhängigkeit der Kernbereiche halt mit mehr oder weniger Unterbrechungen. Und wenn die Firma mal einen Arbeitstag verliert, oder die Produktion steht, weil der Admin etwas installiert hat, was nicht getestet war, dann will ich nicht in seiner Haut stecken.
Die Frage ist nur: wie tiefgehend ist diese Testumgebung? Beziehe ich mich rein auf eben die Produktionssoftware und derern Einstellugen oder gehört da auch das darunter liegende OS mit dazu? Oder verlasse ich mich beim OS auf den Distributor, der ja schon entsprechend getestet hat?
Manche Systeme lassen sich auch "schwer" (*) in Testszenarien abbilden - nicht jede Firma hat die Mittel, z.T. Hunderttausende von Euros einfach nur "zum Spass" in HW und Software vorrätig zu halten...
(*) aus betriebswirtschaftlicher Sicht.
Ich wünschte man würde das... bei uns (XP - System) geh ich jedes mal die Wände hoch wenn ungetestet Patches per Skript über Nacht eingespielt werden.. zumal die mir oft meine MS Office Einstellungen "zurücksetzen" ..... hilft nix.. passiert jedes mal wieder... daher ist meine Suse Installation auf meinem Frickel-PC zuhause stabiler als die XP Installation mit der ich im Job arbeiten muss... obwohl _der_ von "Profis" administriert wird .....
Deine Tatstatur ist kaputt :rolleyes:
Wenn Du die Stabilitätsprobleme lösen kannst fasse dir nötigen Änderungen am Deployment doch für euren Admin zusammen. :)
Dann sieht er's auch lockerer das du denhalben Arbeitstag surfst anstatt zu Arbeiten ;)
mfg
cane
Manche Systeme lassen sich auch "schwer" (*) in Testszenarien abbilden - nicht jede Firma hat die Mittel, z.T. Hunderttausende von Euros einfach nur "zum Spass" in HW und Software vorrätig zu halten...
(*) aus betriebswirtschaftlicher Sicht.
ACK!
*zehnzeichen*
Deine Tatstatur ist kaputt
Hmm.. kann sein.... muss daran liegen dass ich ab und zu mit dem Kopf draufrumhämmere .... :D
Auf meinem Desktop (Ubuntu 7.10) läuft der Exploit 1A. Auf meinem Webserver mit grSecurity schlägt er fehl :p
nochmal ne technische Frage dazu. Reicht es nicht einfach /proc/kallsyms das Recht fuer other zu entziehen?
suckless:~> ls -l /proc/kallsyms
-r--r--r-- 1 root root 0 2008-02-13 23:50 /proc/kallsyms
nochmal ne technische Frage dazu. Reicht es nicht einfach /proc/kallsyms das Recht fuer other zu entziehen?
suckless:~> ls -l /proc/kallsyms
-r--r--r-- 1 root root 0 2008-02-13 23:50 /proc/kallsyms
Warum probierst du es nicht einfach aus?
Gruß
Oliver
Ich habe leider kein Debian ATM. bzw, keine Rootrechte auf der Kiste.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.