Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Core » OS & kernel » Linux » Zwakte in geheugenbeheer Linux maakt root-toegang mogelijk

Zwakte in geheugenbeheer Linux maakt root-toegang mogelijk

Door Wout Funnekotter, maandag 23 januari 2012 14:55, views: 37.919

Een zwakte in het geheugenmanagement van Linux maakt het mogelijk om naar het geheugen van een ander proces te schrijven. Op deze wijze kan root-toegang worden verkregen. Een patch om het probleem te verhelpen is al ingediend.

Tux (linux logo, kleiner met schaduw)Jason Donenfeld plaatste op zijn blog een uitgebreide beschrijving van de zwakte, inclusief voorbeeldcode waarmee root-toegang op een Linux-systeem verkregen kan worden. De zwakte is te vinden in de beveiliging van /proc/pid/mem, de interface waarmee naar procesgeheugen geschreven kan worden. De beveiliging die ervoor zorgt dat een proces alleen naar zijn eigen stukje geheugen kan schrijven, blijkt niet afdoende.

Donenfeld ontdekte een manier om die beveiliging te omzeilen waarna hij bij het geheugen dat aan een su-proces toebehoorde kon komen. Daarin injecteerde hij een stuk code waardoor hij met root-toegang een shell kon starten. De code die Donenfeld publiceerde is inclusief comments nog geen 200 regels lang en kan overweg met zowel 32- als 64-bits-systemen. 

Volgens Donenfeld is de Linux-kernel vanaf 2.6.39 vatbaar voor de exploit. Enkele dagen geleden is al een patch die de exploit onmogelijk moet maken ingediend en goedgekeurd. Uit een korte test blijkt dat een volledig gepatchte versie van Ubuntu 11.10 in ieder geval vatbaar is voor de exploit. Ook sommige recente Android-telefoons zouden in theorie vatbaar zijn, omdat het mobiele besturingssysteem op Linux gebaseerd is.

Volgende 15:12 Gaikai gaat volledige games streamen
Vorige 13:42 Sony introduceert smartphonebeeldsensors met rgbw-lay-out
Advertentie

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 108 reacties zichtbaar1080 Off-topic / Irrelevant: 103 reacties zichtbaar103+1 On-topic: 71 reacties zichtbaar71+2 Informatief: 5 reacties zichtbaar5+3 Spotlight: 0 reacties zichtbaar0
«  1  2  3  »

Door judgewooden, maandag 23 januari 2012 14:57

Score: 1
Android is niet kwetsbaar, want die kernel is al geforked voor versie 2.6.39!

Door ritsjoena, maandag 23 januari 2012 14:59

Score: 1
Android is niet kwetsbaar, want die kernel is al geforked voor versie 2.6.39!
Het kan zijn dat ze bij de ontwikkeling van Android nieuwere Linux code hebben overgenomen, danwel iets vergelijkbaars hebben gemaakt. Dit kan verklaren waarom er sommige staat en niet alle.

Door ThomasG, maandag 23 januari 2012 15:00

Score: 1
Dat betekend niet per definitie dat Android niet kwetsbaar is, hoewel het daarvoor al geforked is zou het best kunnen dat het een en ander is overgenomen, uit o.a. (beveiligings) updates waar de code die deze fout veroorzaakt tussen staat.

Door himlims_, maandag 23 januari 2012 15:01

Score: 0
hahaha en alle reeds uitgegeven android telefoons draaien op die versie? en zijn eenvoudig te updaten naar die versie? ..... Nee!

Door hostname, maandag 23 januari 2012 15:09

Score: 1
Alle versies voor 2.6.39 zijn juist niet kwetsbaar...

Door SirNobax, maandag 23 januari 2012 15:12

Score: 1
Juist, vrijwel elk Android 2.3 of 3.1 toestel draait op Linux kernel 2.6.35 of 2.6.36.
Enkel ICS heeft een recentere kernel.

Door demilord, dinsdag 24 januari 2012 02:52

Score: 0
Alle versies voor 2.6.39 zijn juist niet kwetsbaar...
thnx draai 2.6.38-8

Door merethan, maandag 23 januari 2012 16:16

Score: 1
himlims, nieuwere versie betekent niet perse veiliger of beter. Bugs worden niet alleen maar uitgeroeid, er worden ook nieuwe geïntroduceerd. In dit geval op 2.6.39. En de kernel van Android is geforked vanaf 2.6.30 ofzo.

Door Sir Guinhill, maandag 23 januari 2012 15:07

Score: 1
De Kernel voor ICS op mijn Sensation is versie 3.0.16.
Ik neem aan dat deze versie een fork is die ook vanaf de main linux kernel is gemaakt. En niet een doorontwikkeling is van de 2.x kernel.

Dus voor ICS kan het best zijn dat dit een nieuwe optie is om root toegang te krijgen.

Ik vraag me alleen af hoe makkelijk deze "zwakte" van buiten af uit te buiten is.
Als je door een zwakte in een service ( zoals b.v. apache e.d. ) de account die deze service draait de code kan laten uitvoeren die SU toegang forceert... Dan is geen webserver meer veilig.

Door arjankoole, maandag 23 januari 2012 15:56

Score: 1
Als je door een zwakte in een service ( zoals b.v. apache e.d. ) de account die deze service draait de code kan laten uitvoeren die SU toegang forceert... Dan is geen webserver meer veilig.
Je bent sowieso vaak al het haasje als iemand zo binnen komt. Ik heb ook wel eens iemand binnen zien komen via een lek php script (vaak een groter risico dan een lek in apache), om vervolgens via een lek in se-linux (oh, the irony) root te worden. Dat koste aardig wat moeite om dat figuur weg te krijgen. (en uiteindelijk heeft die box een total whipe gekregen, ook al was ik er 99,9999% zeker van dat ie niet meer binnen kon komen via z'n backdoors, puur om het zekere voor het onzekere te nemen)

Door iChaos, maandag 23 januari 2012 16:35

Score: 1
3.0.16 is voor zover ik weet wel doorontwikkeld vanaf 2.X, want bij mijn weten is er dus toen de ontwikkeling bij 2.6.40 aankwam, deze gelijk omgedoopt naar 3.0.

Door Trashed, maandag 23 januari 2012 17:20

Score: 1
Klopt... de 3.x kernels hadden dus ook 2.6.x (of 2.7.x) kunnen heten. Bij mijn weten is de 3 geïntroduceerd om een nieuw decennium aan te duiden (de 2.x kernel ging alweer 10 jaar mee dus).

Door IEF, maandag 23 januari 2012 17:13

Score: 1
shell@android:/ $ uname -a
Linux localhost 2.6.39.4 #1 SMP PREEMPT Tue Jan 17 21:01:44 CST 2012 armv7l GNU/Linux
shell@android:/ $ /data/local/mempodroid
shell@android:/ # id
uid=0(root) gid=0(root)
shell@android:/ #
You were saying? (Transformer Prime)

Voor alle duidelijkheid, dit is een zgn. local root. Op android heb je dan ook in elk geval de 'shell' user nodig om root te kunnen worden, dus via 'adb shell', maw. met een usb kabeltje.
Autonoom (bijvoorbeeld via een Android App) kan dit dus niet.

[Reactie gewijzigd door IEF op maandag 23 januari 2012 17:16]

Door Aphax, maandag 23 januari 2012 18:24

Score: 1
Uit nieuwsgierigheid, is het niet mogelijk dit vanuit een Android app met native code te doen?

Mijn TF101 heeft trouwens een oudere kernel (2.6.36), heb jjij 2.6.39 deze er zelf op gezet, of ben ik een update misgelopen?

[Reactie gewijzigd door Aphax op maandag 23 januari 2012 18:26]

Door midy922, dinsdag 24 januari 2012 14:55

Score: 0
Transformer Prime mèt ICS heeft kernel 2.6.39.4.

Door dtech, maandag 23 januari 2012 18:17

Score: 1
Android 4 is gebaseer op Linux kernel 3.0.1. De Android kernel wordt elke keer opnieuw gepatched voor Android, het is dus geen fork zoals jij impliceert.
Android is dus zeker wel vatbaar voor deze exploit.

Door Kees de Jong, dinsdag 24 januari 2012 01:21

Score: 1
ieder OS is kwetsbaar als het interessant genoeg is om te exploten doet men heus wel genoeg moeite om dit te bewerkstelligen.

Om op internet te kunnen communiceren staan er poorten open, waar een open deur (poort) is daar is altijd een weg naar binnen te vinden.

Sinds Android veelvuldiger op mobiele telefoons gebruikt wordt en veel mensen daar nu hun bankzaken mee doen is het logisch dat Linux nu interessanter is en dus vaker onder de loep wordt genomen.

[Reactie gewijzigd door Kees de Jong op dinsdag 24 januari 2012 02:42]

Door Eagle Creek, maandag 23 januari 2012 14:58

Score: 1
Enkele dagen geleden is al een patch die de exploit onmogelijk moet maken ingediend en goedgekeurd. Uit een korte test blijkt dat een volledig gepatchte versie van Ubuntu 11.10 in ieder geval vatbaar is voor de exploit.
Ik vind bovenstaand stukje een beetje onduidelijk weergegeven.

Betekent dit dat de betreffende (ingediende en goedgekeurde) patch het probleem niet oplost (en nog steeds root-toegang mogelijk is), of bedoelt men met "een volledig gepatche versie van Ubuntu" een versie zonder bovengenoemde patch, maar wel met alle andere beschikbare patches (hence: je moet bovengenoemde patch alsnog installeren om het probleem te verhelpen)?

[Reactie gewijzigd door Eagle Creek op maandag 23 januari 2012 15:02]

Door MadEgg, maandag 23 januari 2012 15:01

Score: 1
Ik denk dat deze specifieke patch nog niet uitgerold is op Ubuntu, maar wel is ingediend bij de kernel developers. Zal een kwestie van uren zijn voordat deze update via de diverse distro's wordt uitgerold denk ik, nadat het in de publiciteit is gekomen.

Door Trashed, maandag 23 januari 2012 17:24

Score: 1
Geen idee of dit inmiddels wél het geval is, maar ik krijg nu net de nieuwste update (inclusief kernel patch) binnen terwijl die pas is bijgewerkt. Wellicht vanaf nu dus wél uitgerold.

Door hackerhater, maandag 23 januari 2012 18:10

Score: 1
Update van vandaag
"Revert "proc: enable writing to /proc/pid/mem""

Jup dit is die

Door MadEgg, maandag 23 januari 2012 22:12

Score: 1
Check, net geupdate en de exploit werkt nu niet meer.

Door Carharttguy, maandag 23 januari 2012 15:01

Score: 1
De patch zal het probleem waarschijnlijk wel verholpen hebben, maar het duurd meestal nog even voor alle distributies de patch opnemen, en pushen naar de gebruikers. (kwestie van maximum enkele dagen (meestal uren))

[Reactie gewijzigd door Carharttguy op maandag 23 januari 2012 15:03]

Door Neko Koneko, maandag 23 januari 2012 15:03

Score: 1
De patch is ingevoerd en goedgekeurd, maar dat betekent niet niet dat hij al is gepubliceerd bij de afzonderlijke distro's. Op dit moment is Ubuntu dus met alle patches die op dit moment beschikbaar zijn nog steeds kwetsbaar.

Door Bjornski, maandag 23 januari 2012 15:03

Score: 1
De patch is ingediend voor de Linux kernel. Ubuntu moet die eerst overnemen (of de hele kernel, of de patch). Hiermee toont men aan dat veel standaard distributies waarschijnlijk vatbaar zullen zijn.

Door Jorik, maandag 23 januari 2012 14:59

Score: 2
saurik heeft al een exploit voor de Galaxy Nexus geschreven.

Door Camembert1633, dinsdag 24 januari 2012 01:01

Score: 1
Deze exploit is dus geschikt voor de galaxy nexus en de transformer prime.

Maar kan deze exploit dan gebruikt worden voor elke android versie? Aangezien deze exploit er al veel langer in zit. Saurik heeft zelf waarschijnlijk een nexus en een prime.

Door Essox_Kill8ox, maandag 23 januari 2012 15:01

Score: 1
Naast dat er op de meeste Linux machines allerlei veiligheidsmaatregelen ingebouwd zijn (ASLR) en er op de machine waarschijnlijk ook wel AppArmor o.i.d. geïnstalleerd is, kan ik met zekerheid zeggen dat deze 'gevaarlijke bug' en een lek in de geheugen beheer niet op iedere machine zal leiden tot een succesvolle inbraak.
Stel dat je via USB wél toegang zou krijgen op kernel niveau, het geeft jou dan dus geen rootrechten.
Daarvoor moet je je ook weer in allerlei bochten wringen... dus dan moet je nog wat hacken.
Op veel linux machines hebben auto-parsers weinig kans en niet elk script laat zich pushen.

Dit is niet geldig voor alle Linux versies.

http://security-tracker.debian.org/tracker/CVE-2012-0056

en de patch is inmiddels vrijgegeven:

http://git.kernel.org/?p=...7efd422a804dbb27977a3cccc


author Linus Torvalds <torvalds@linux-foundation.org>
Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)
committer Linus Torvalds <torvalds@linux-foundation.org>
Tue, 17 Jan 2012 23:21:19 +0000 (15:21 -0800)
Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very
robust, and it also doesn't match the permission checking of any of the
other related files.

This changes it to do the permission checks at open time, and instead of
tracking the process, it tracks the VM at the time of the open. That
simplifies the code a lot, but does mean that if you hold the file
descriptor open over an execve(), you'll continue to read from the _old_
VM.

That is different from our previous behavior, but much simpler. If
somebody actually finds a load where this matters, we'll need to revert
this commit.

I suspect that nobody will ever notice - because the process mapping
addresses will also have changed as part of the execve. So you cannot
actually usefully access the fd across a VM change simply because all
the offsets for IO would have changed too.

Reported-by: Jüri Aedla <asd@ut.ee>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

[Reactie gewijzigd door Essox_Kill8ox op maandag 23 januari 2012 15:41]

Door MadEgg, maandag 23 januari 2012 15:15

Score: 1
-edit-
Ongewenst ? en waarom?
Waarschijnlijk door je formulering in je originele post, wat je nu weggeedit hebt... 'geloof mij nou maar' komt niet echt over als een solide argumentatie!

Ik denk dat je het lek iets te veel bagatelliseert; het is wel degelijk een vrij ernstig lek. Gelukkig zijn er in redelijk wat situaties aanvullende maatregelen getroffen waardoor het niet universeel toepasbaar is, maar wel jammer dat het gebeurt. Wel wederom snel gepatcht, maar we zijn niet anders gewend van de kernel developers.

Door Stoney3K, maandag 23 januari 2012 15:29

Score: 1
[...]


Waarschijnlijk door je formulering in je originele post, wat je nu weggeedit hebt... 'geloof mij nou maar' komt niet echt over als een solide argumentatie!
Bovendien klinkt het als een verhaal wat (naast het gezever over moderaties in je post) compleet kant noch wal raakt.

Dit gaat niet over toegang tot het kernel-geheugen, al dan niet via scripts of parsers, maar over een stuk code wat blijkbaar door een overflow lek is en dus code als root (buiten het stukje wat voor jou 'beschermd' als gebruiker is gereserveerd) uit kan voeren.

Wat je dan als root doet is weer een tweede: In de demonstratie die boven staat is het het uitvoeren van een shell, maar je kan natuurlijk veel vervelender dingen uithalen, want als root kom je OVERAL bij. Daar heb je dus geen USB, parsers of wat dan ook voor nodig, alleen een (userland) account op de machine die je wil aanvallen en een mogelijkheid om je eigen code uit te kunnen voeren: Iets wat één van de eigenschappen is van een multi-user OS zoals Linux.

Door jon.kiji, maandag 23 januari 2012 15:49

Score: 1
En er dan ook even vanuit gaand dat er geen mandatory access control zoals selinux draait. Want daarmee dam je zelfs de rechten van de root user in.

Door Caelestis, maandag 23 januari 2012 18:01

Score: 1
Het is niet zo dat je door een overflow automatisch root rechten krijgt het gaat erom dat je code kan injecteren in een proces welke met sudo is gestart en via dat sessie de rechten krijgt.
In telefoons gebruik je ziezo geen sudo om dingen uit te voeren dus ook al is het exploit aanwezig zijn andriod telefoon onkwetsbaar. Tevens is de vraag dan hoe vaak iemand nou werkelijk het sudo cmd aanroept in zijn linux omgeving?

Het is typisch zo'n geval van weet wat je doet en er kan je niks gebeuren maar als je overal op klikt dan vraag je erom en is geen enkel beveiliging goed genoeg anders dan je verbannen van het computer in zijn geheel.

Door Dreamvoid, maandag 23 januari 2012 15:33

Score: 0
Wel wederom snel gepatcht
2.6.39 is alweer acht maanden oud, dus niet zo heel erg snel.

Door MadEgg, maandag 23 januari 2012 16:02

Score: 1
Snel gepatcht nadat het lek bekend wordt natuurlijk. Dat de fout erin zit is jammer, maar zo lang het probleem niet bekend is kan het natuurlijk ook niet opgelost worden. Aan de andere kant, zolang het probleem niet bekend is kan het ook niet misbruikt worden.

Door mjtdevries, maandag 23 januari 2012 16:15

Score: 2
Zolang het probleem niet bekend is bij kwaadwillende kan het ook niet misbruikt worden.

Het punt is echter dat het probleem nu 8 maanden niet bekend was bij goedwillenden en we niet weten of kwaadwillende het wel wisten. Want die gaan dat niet aan de grote klok hangen.

Door MadEgg, maandag 23 januari 2012 21:53

Score: 1
Het risico is inderdaad aanwezig. Toch hebben kwaadwillenden de neiging om dan de code te misbruiken waardoor er in ieder geval aan het licht gekomen was dat er een nieuw soort hack in omloop was, en zodra er ergens een exemplaar van werkende code opgedoken was had iemand dat kunnen reverse engineeren om zo alsnog het probleem op te sporen.

Bovendien zie je bij Linux toch wel vaak dat het niet echt getarget wordt, juist omdat het ook vaak het OS of choice is van de hackers zelf.

Door aTmosh, maandag 23 januari 2012 23:14

Score: 1
In alle software die complex genoeg is zitten fouten, dat is een gegeven waar je mee moet leven.

Wat in deze eerder van belang is zijn de gevolgen in patchsnelheid vanwege filosofie/bedrijfsmodel. Voor Linux geldt "zo snel mogelijk" (doorgaans uren na bekendwording), voor Windows "Hoeveel geld kost de PR schade als we het tot/na dinsdag laten liggen?".

Helaas komt het geregeld voor dat Microsoft iets jaren laat liggen waar ze al van weten, danwel dat iemand die een fout in MS' software vindt genoodzaakt is deze bekend te maken omdat zij anders geen reden zien om deze te patchen.

Door SED, dinsdag 24 januari 2012 10:16

Score: 0
Dit is onzin. De patchsnelheid van Windoes ligt erg hoog maar ze moeten met veel meer zaken rekening houden. Commerciele motieven spelen daar ongetwijfeld een rol, maar meer de vraag of een snelle slecht geteste patch meer schade kan aanrichten dan kan oplossen en hoe dit te voorkomen.
Men laa thet ook niet uit PR oogpunt liggen maa rom de zaken voor pros hanteerbaar en testbaar te maken. Zo maar even een patch uitrollen op een server doe je niet in productie en daar zijn testprocedures voor. Toch al opvallend dat velen in de linuxcommunity enekel uren na het uitbregen deze patch ongetest lijken uit te rollen. dan zit er meestal geen commercieel gevolg aan lijkt me zo.

Door aTmosh, woensdag 25 januari 2012 07:20

Score: 0
Dit is onzin:
FTFY

Ligt de patchsnelheid nu hoger of lager dan bij Linux? Je probeert het tegelijkertijd te doen voorkomen alsof de snelheid hoger ligt met waarom het beter is dat de snelheid lager ligt m.b.v. welklinkende vaagheden als "beter voor de pro's".

Het moge duidelijk zijn dat 1 patchdag per maand, met uitzonderlijke out of cycle patches niet sneller kan zijn dan een fix die binnen enkele uren klaarligt, en jawel, getest en in distributies is opgenomen. Een betere vraag zou zijn of het doeltreffender is om een constante stroom van snelle patches te hebben dan een regelmatige dump van veel patches ineens. In mijn ogen duidelijk het eerste, omdat je dan als beheerder zelf kan bepalen wat je ermee doet, b.v. cherrypicken wat voor jou interessant is, wachten op een service window etc.

En geloof me, ik ben een pro, met jarenlange ervaring in een gemengde Windows/Linux omgeving met honderden servers waar patches zeer snel worden uitgerold. Dat kan als je design goed is, m.n. redundantie op alle niveau's. Testen doe je in een identieke stagingomgeving en/of virtualisatie met testharnas, loadgeneratie etc. We hebben het hier over 8 cijferige bedragen met nette SLA's en boeteclausules.

Het is ook complete onzin dat Linux patches niet goed getest zouden worden door de programmeurs, ik heb dat op OS vlak helemaal niet meegemaakt, maar heb me wel doodgeërgerd aan Windows omdat het daarmee wel regelmatig misgaat en doorgaans niet zo eenvoudig teruggerold kan worden.

Ik vind het juist opvallend dat er zoveel M$ apologisten rondlopen hier die de gebruikelijke FUD en TCO PR als zoete koek slikken, zonder over de externalisaties na te denken.

Door FunFair, maandag 23 januari 2012 15:02

Score: 1
Het is wel grappig, dat voor de Ubuntu users dit een ongewenste bug is.. en voor bijvoorbeeld Android users dit een leuke feature is, als de fabrikant root niet toestaat :)

Door MartijnHavinga, maandag 23 januari 2012 15:13

Score: 2
'k zou het een minder leuke "feature" vinden als ik een programma installeer dat alleen maar internet rechten nodig heeft vanuit de market, en dat ik er dan later achterkom dat hij mijn hele telefoon heeft leeggetrokken qua persoonlijke data, en ook nog eens een keylogger heeft geïnstalleerd...

Door MadEgg, maandag 23 januari 2012 15:18

Score: 1
True, maar als je hierdoor eenvoudig kan jailbreaken en jezelf op die manier permanent root toegang kan verschaffen is het wel een leuk bijgevolg.

Door Dreamvoid, maandag 23 januari 2012 15:25

Score: 1
Jij niet, maar iemand die zijn toestel wil jailbreaken/rooten heeft zulke exploits nodig.

Door watercoolertje, maandag 23 januari 2012 15:55

Score: 1
Daar heb je zeker een punt, elke hack die 'goedaardig' te gebruiken is is ook kwaadaardig te gebruiken...

Ik heb dan ook nooit begrpeen waarom niemand een kwaadaardig iets heeft geschreven voor iOS waar je bijv voorheen via de browser root kon verkrijgen!

Door tiranofice, maandag 23 januari 2012 15:57

Score: 0
Daar heb je zeker een punt, elke hack die 'goedaardig' te gebruiken is is ook kwaadaardig te gebruiken...

Ik heb dan ook nooit begrpeen waarom niemand een kwaadaardig iets heeft geschreven voor iOS waar je bijv voorheen via de browser root kon verkrijgen!
Je weet niet of zoiets bestond. Als dat op kleine schaal werd gebruikt neem ik aan dat dit ongemerkt kan blijven. IOS heeft immers geen virusscan ofzo.

Door r03n_d, maandag 23 januari 2012 15:09

Score: 1
Vraag me alleen af wat dit zou kunnen betekenen voor kwaadwillenden. Volgens mij zijn er nu een aantal nieuwe 'hacks' in de maak die gretig gebruik zullen maken van deze ontdekking.

Door MadEgg, maandag 23 januari 2012 15:12

Score: 1
Dat zal waarschijnlijk aardig meevallen, binnen korte tijd zullen patches over alle distros uitgerold worden die over het algemeen automatisch geinstalleerd zullen worden waardoor de systemen niet kwetsbaar meer zijn.

Ook zal bovengenoemde AppArmor e.d. op servers waarschjinlijk het gevolg hebben dat deze exploit alsnog niet gebruikt kan worden omdat deze nog extra beveiligingsrestricties oplegt aan waar geschreven kan worden bovenop de security features van de kernel zelf, die in dit geval dus duidelijk tekort schieten.

Door Carharttguy, maandag 23 januari 2012 15:13

Score: 0
Als je nu nog maar begonnen bent met het maken van een hacktool, ben je al veel te laat, de patch is al ingediend, distributies zijn binnen enkele uren veilig.

Door Dreamvoid, maandag 23 januari 2012 15:18

Score: 0
Behalve alle routers, telefoons, servers, etc die niet of pas later hun kernel updaten. Er is geen manier om een update naar *alle* clients te forceren.

[Reactie gewijzigd door Dreamvoid op maandag 23 januari 2012 15:24]

Door watercoolertje, maandag 23 januari 2012 15:57

Score: 1
Die groep is dan ook veel te gefragmenteerd (de rede waarom er vaak geen update voor komt is juist omdat er niet enorm veel gebruikers zijn), het kan inderdaad onveilig zijn maar de hacker heeft zo klein bereik en moet zo goed zoeken om de mensen te vinden dat het het vaak niet waard is, lang leve fragmentatie zeg ik dan maar :D

Door The Zep Man, maandag 23 januari 2012 16:45

Score: 2
Behalve alle routers, telefoons, servers, etc die niet of pas later hun kernel updaten. Er is geen manier om een update naar *alle* clients te forceren.
Er is nog steeds lokale (shell) toegang nodig voordat deze exploit uitgevoerd kan worden. Het lek lijkt ernstig, maar is vergelijkbaar met exploits in Windows waarvoor maandelijks security updates worden uitgebracht met een omschrijving van Microsoft die als volgt begint:

"A security issue has been identified that could allow an authenticated local attacker to compromise your system and gain control over it."

Het is niet alsof iemand op afstand zonder toegang tot het systeem plots wel toegang heeft en rootrechten kan opeisen. In één van de lagen in het complete spectrum van buitenwereld (anonieme/niet ingelogde gebruikers) tot volledige controle over het systeem zit nu een gat. Dit zorgt er niet voor dat de andere beveiligingslagen ook automatisch falen.

Kort samengevat: als niemand kan inloggen op je router, is er niets aan de hand. Als iemand met kwade bedoelingen wel kan inloggen heb je vaak al grotere problemen dan alleen deze exploit. Overigens hebben consumentenrouters en soortgelijke apparatuur vaak maar een enkel root gebruikersaccount en is dit verhaal sowieso niet van toepassing.

[Reactie gewijzigd door The Zep Man op maandag 23 januari 2012 16:48]

Door Caelestis, maandag 23 januari 2012 18:14

Score: 1
Is niet belangrijk.
Als het bedrijf niet snel is met het updaten van zijn producten om te pushen dan is de kans ENORM groot dat ze niet eens de juiste versie kernel gebruiken.

Alleen degene die bij blijven met updates en deze regelmatig laten bijwerken kunnen hier last van krijgen en zijn dan ook gelijk snel genoeg om het probleem uit de wereld te helpen.

Door jon.kiji, maandag 23 januari 2012 15:31

Score: 0
Hum. Mijn arch doos die nu toch al een paar weken ongeüpdate draait op 3.1.3-1 is niet vatbaar.

Door anton_89, maandag 23 januari 2012 16:19

Score: 1
Arch met kernel 3.2.1-1 is ook niet vatbaar. Maar op Mint met dezelfde kernel doet ie het wel schijnbaar, zie post van Linux-TUX. Vreemd, Arch heeft meestal een zo stock mogelijke kernel.

Door Dabono, maandag 23 januari 2012 17:46

Score: 1
Reden hiervoor wordt op het blog vermeld:
"It turns out that su on the vast majority of distros is not compiled with PIE, disabling ASLR for the .text section of the binary!"

Voorwaarde voor de hack is dus dat 'su' zonder PIE gecompiled is, wat blijkbaar bij Arch niet het geval is en bij Mint wel.

Door Ventieldopje, maandag 23 januari 2012 15:32

Score: 1
Knap dat ze dit gevonden hebben! Ik heb net even gekeken op OpenSUSE 12.1 (kernel 3.1) maar "su" is hier gepatcht, de kernel zelf weet ik niet maar neem aan van wel.

Goed dat ze dit soort dingen aan het licht blijven brengen! :)

Door jon.kiji, maandag 23 januari 2012 15:46

Score: 1
Eerst even Nederlands leren en een beetje leren onderbouwen.

Wie zijn 'hun', welke 'andere lekken' en wie moet daar over spreken, waaruit blijkt dat het 'zo onveilig als maar zijn kan' is?

Een beetje discussie is niet erg, maar graag wel onderbouwen, anders hebben wij ook niets om over in discussie te gaan.

Door MSalters, maandag 23 januari 2012 16:37

Score: 1
Dan zijn er geen bekende lekken. Veiligheid is groter naarmate er minder fouten worden gevonden en naarmate fouten sneller worden opgelost. De grootste klacht bij Microsoft is dat fouten langzaam worden opgelost. Deze Linux fout, ter vergelijking, is blijkbaar al opgelost.

Door arjankoole, maandag 23 januari 2012 16:42

Score: 1
HUN - Linux / Android beheerders
Nou goed je leest zoveel dat er updates komen vanwege veiligheid redenen, net als windows.. Terwijl je nu ook weet dat er volgend jaar weer een lek zal worden gedicht.. En hoe zit dat dan in die tussentijd??
In de tussentijd wordt ieder lek - dat ontdekt wordt - gewoon gedicht. Maar onbekende lekken kun je ook niet dichten.

Het grote verschil tussen Microsoft en de Linux community is dat je Microsoft soms / vaak moet dwingen met full-disclosure voor Redmond ook maar 1 milimeter in beweging komt. Bij Opensource besturingssystemen is dat toch een heel ander verhaal.

Door sfranken, maandag 23 januari 2012 19:23

Score: 1
Linux word door een gigantische groep vrijwilligers beheerd, en die patchen zoiets binnen ~48 uur.

Microsoft heeft honderd duizendend mensen in dienst en daar duurt het wat, twee/drie weken voordat zo'n update uikomt.

Petje af. Bovendien is Linux een hobbymatig project waar vrijwilligers aan werken, en waar mensen werken worden fouten gemaakt (of ga jij even 1 miljoen+ regels code op foutjes controleren?)

Zoals jon hierboven zei: Leer je eigen taal behoorlijk spellen/spreken en leer de kunst der "je mening onderbouwen". Dan kunnen we praten.

Door erikdenv, maandag 23 januari 2012 20:36

Score: 1
Er werken ook veel mensen beroepsmatig aan Linux. Dit zijn bijvoorbeeld mensen die indienst zijn van Redhat, Suse, IBM of Google.

Door Texamicz, dinsdag 24 januari 2012 08:32

Score: 0
Nah dat niet alleen ook gewoon gebruikers die het op hun werk gebruiken. Als deze beheerders een beetje into Linux zijn weten ze wel het laatste nieuws en hoe ze alles binnen een paar uur kunnen patchen. Zo flexibel is Linux wel.

Door whitewidowNL, maandag 23 januari 2012 16:25

Score: 0
Nou goed ten eerste mijn excuses voor dat ''wazige'' bericht, net een boterhammetje gegeten en ik ben weer op deze planeet..
Ik gebruik een win 7 ''apparaatje'' en voel me ook zeker niet veiliger dan met een Linux machine. Maar goed het gaat hier niet om Windows maar om Linux en Android volgens mij?
Het gaat me er min of meer om hoe dat met andere lekken zit, want je bent ook na deze update niet veilig vanwege andere lekken die in de toekomst gedicht zullen worden?

Hoe doet het mac os het op dit gebied eigenlijk?

Door arjankoole, maandag 23 januari 2012 16:45

Score: 1
Als ik je posts over dit onderwerp eens lees, krijg ik het idee dat je de materie niet volledig meester bent.

Hoe wil je je beschermen tegen een lek wat niet bekent is, of sterker nog, waar de code nog niet eens geschreven is?

Pas als een bug/fout ontdekt is, kun je ontdekken of dat ook te misbruiken is, daarna kun je pas gaan denken aan een bescherming (lees: code fix) schrijven. Niet eerder dan dat. En dat is voor alle besturingsystemen gelijk.

Door bwerg, maandag 23 januari 2012 20:05

Score: 1
Zelf ooit iets geprogrammeerd? Dan weet je dat het onmogelijk te garanderen is dat je programma bugvrij is, en een gigantisch en complex OS heeft uiteraard bugs. Dat heeft linux, windows, OSX... in alle zitten onontdekte bugs, en met alle updates worden er nog meer bugs geïntroduceerd (hopelijk fixen ze er meer dan dat er nieuwe bijkomen natuurlijk). Als je bij een willekeurig OS net een update hebt doorgevoerd, garandeer ik je dat er nog steeds bugs inzitten waaronder vaak ook beveiligingslekken (oke, alleen bij zo'n vaag academisch OS dat bewezen bugvrij is niet, maar daar kan je dan ook niets praktisch mee).

Ik zie ook niet waarom daarin een verschil zou zijn tussen verschillende OS'en, behalve misschien in hoe snel ze dat oppakken maar ik denk dat dat bij alle makers van grote OS'en snel gefixt is, zodra een bug ontdekt wordt.

[Reactie gewijzigd door bwerg op maandag 23 januari 2012 20:08]

Door Ventieldopje, dinsdag 24 januari 2012 01:40

Score: 0
Ik raad je aan even de link te volgen blog.zx2c4.com/749, dan even hier terug te komen en ons nou eens haarfijn uitlegt waarom jij deze bug wel gevonden zou hebben.

Als je zelf nooit geprogrammeerd hebt en al helemaal zo ergens op loopt te bashen waar je totaal geen verstand van hebt zul je er niks van snappen. Hopelijk snap je wel één ding, dat het niet zo simpel is als jij doet blijken ;)

Door watercoolertje, maandag 23 januari 2012 15:59

Score: 1
Ach tot nu toe is elk OS jailbraikbaar of rootbaar of dat nou deze specifieke manier is of een andere manier is niet zo relevant...

Door Carharttguy, maandag 23 januari 2012 16:06

Score: 1
Ik denk dat er in Linux evenveel fouten zitten als in Windows/Mac, alleen dat ze door meer mensen kunnen worden opgespoord (maar natuurlijk ook gevonden en misbruikt!)

Maar om nu te zeggen dat het zo onveilig zijn als het maar kan zijn, dat betwijfel ik toch als je naar het aantal virussen kijkt voor het Linux systeem tegenover het Windows systeem.

Als ze willen, geraken ze binnen, maar bij Linux zien ze het nut er blijkbaar niet van in, dus ben je uiteindelijk waarschijnlijk toch nog veiliger dan een meer gebruikt systeem.

(ik heb het over desktops, bij Android ben je evengoed kwetsbaar, daar dit wel een populair systeem is!)

Door whitewidowNL, maandag 23 januari 2012 16:27

Score: 0
Ja natuurlijk dat zo onveilig als maar zijn kan was ook overdreven, mijn excuses.

Ja ik begrijp ook wel dat er meer virussen zijn voor windows dan voor linux, is dit niet simpelweg omdat er veel meer windows gebruikers zijn en je dus meer kanten op kan met een virus??

Door EpicEraser, maandag 23 januari 2012 16:29

Score: 0
Ik denk niet dat er zo veel beveiligingsfouten zitten in Linux (let op: de kernel) als in de Windows kernel, juist omdat er zo veel mensen het modereren en de meeste mensen die fouten vinden, dit netjes zullen melden, zoals de heer Donenfeld.

OSX (Darwin kernel) kun je beter onder één noemer noemen met Linux in plaats van Windows, omdat Darwin een open source kernel is (en nog meer POSIX-compliant dan Linux).

Software heeft fouten, en kernels zijn ingewikkeld genoeg om de fouten lastig te vinden te maken.

Overigens heb ik dit net getest op Arch 3.2.1-3-ck en het haalt niks uit, zoals het hoort :)

[Reactie gewijzigd door EpicEraser op maandag 23 januari 2012 16:30]

Door whitewidowNL, maandag 23 januari 2012 16:37

Score: 0
Dat klopt, zelf ben ik niet bekend op gebied van Linux, wel werk ik met een programmeur wat natuurlijk wel te spreken is over Linux en niet snapt waarom kladblok van windows nog lekken heeft

Danku voor de info.

Door aTmosh, maandag 23 januari 2012 23:53

Score: 0
Er zullen per definitie meer fouten zitten in software die onderhevig is aan een ontwikkelingsmodel dat gebonden is aan deadlines die door commerciële belangen worden bepaald.

Ten tweede zullen er ook meer fouten zitten in closed source software vanwege het beperkte toegang tot de code ter controle (hier is onderzoek naar gedaan).

Daartegenover zou je kunnen stellen dat een closed source project beter onder controle gehouden kan worden door minder variërende bijdragen (zowel in wisselende aantal als kwaliteit van de teamleden), maar daartegenover kun je weer stellen dat de kwaliteit van de programmeurs beter is in open source projecten vanwege de externe factoren zoals meer vrijheid/meer tijd/geen onuitstaanbare managers waar je aan vastzit enz. wat resulteert in minder stress en dus minder fouten. En vaak heb je een community die je niet alleen een hart onder de riem steekt maar vanwege toegang tot de code vaak zelf met patches aankomt.

Door arjankoole, maandag 23 januari 2012 16:46

Score: 0
OSX (Darwin kernel) kun je beter onder één noemer noemen met Linux in plaats van Windows, omdat Darwin een open source kernel is (en nog meer POSIX-compliant dan Linux).
Niet alleen meer POSIX-compliant, volledig. OS X is een officieel gecertificeerde Unix. (en mag zich derhalve ook UNIX noemen)

[Reactie gewijzigd door arjankoole op maandag 23 januari 2012 16:46]

Door merodach, maandag 23 januari 2012 15:42

Score: 1
Zojuist getest op Fedora 16. Deze is ook niet vatbaar.

Door Suspicion, maandag 23 januari 2012 16:43

Score: 1
Heb je dit met of zonder exec shield getest? (sysctl -q kernel.exec-shield)
Misschien is het daarom dat de exploit op sommige distributies niet werkt.
RHEL 6 is ook niet vatbaar trouwens omdat de kernel versie te laag is :) .

Door RSpliet, maandag 23 januari 2012 20:43

Score: 0
En toch komt er een patch uit. Mogelijk dat SELinux hier ingrijpt... of execshield zoals hierboven, of... :)

Door MadEgg, maandag 23 januari 2012 21:51

Score: 0
In de blogpost kan je lezen dat op Fedora /bin/su met position independent code gecompiled is, in tegenstelling tot veel andere distributies. Daarom werkt de code niet as is. Wel heeft dezelfde persoon een alternatief gepubliceerd die wel werkt met Fedora.

Wat er nodig is is een SUID binary die een na aanroep output geeft op stdout of stderr, en die, bij voorkeur, zonder position independent code is gecompileerd. Bij Fedora wordt /bin/gpasswd aangedragen waarvoor dit geldt, ook /bin/eject schijnt te werken. Het varieert dus een beetje per distro welke tool je kunt gebruiken, maar zodra er een SUID binary is die met position independent code is gecompiled kun je deze exploit na kleine aanpassingen gebruiken op een kwetsbare kernel.
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 15:12 Gaikai gaat volledige games streamen
Vorige 13:42 Sony introduceert smartphonebeeldsensors met rgbw-lay-out
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011