Onderzoeker ontdekt gevaarlijke bug in Linux-usb-driver

Reacties

« 1 2 3 »

Door stoepie2002, dinsdag 8 maart 2011 14:43

Ow dit gaat de Linux haters weer voeren....

Technisch gezien is een dergelijke fout natuurlijk zo gemaakt. Dat er iemand ontdekt dat je dit kunt 'misbruiken' is twee.

Vraag me af hoeveel onbekende dingen van soortgelijke aard in Linux/Windows zitten... maar het zullen er best nog wat zijn.

Door Jeroen, dinsdag 8 maart 2011 14:54

Zo blijkt maar weer dat het grootse probleem op gebied van computer security gewoon human error is. Als dit deel grondig volgens de beschikbare theorieen was getest dan had dit voorkomen moeten worden, maar mensen maken natuurlijk fouten en gaan niet altijd even systematisch te werk. Een systeem is zo zwak als de zwakste schakel, of dat nou Windows, Linux, iOS, Mac OS X, Solaris, BSD, Android, of een proprietair systeem, of iets anders is.

Door TRRoads, dinsdag 8 maart 2011 15:04

Duh alle computersystemen zijn door mensen gemaakt, het is dus per definitie human error

Door Jeroen, dinsdag 8 maart 2011 15:09

Nog wel ja, maar is het ook human error als intelligente computerprogramma's code gaan schrijven? Ergens is dat dan namelijk ook indirect door mensen gemaakt

Door damnyankee, dinsdag 8 maart 2011 17:00

Computers merken hele andere dingen dan jij. Daardoor kan jij een security fout zien die een computer niet ziet. Voorbeeldje;

Je koopt een fiets (artikelnummer 123) voor 800 euro online. Je gaat naar het betalingsschermpje, en je ziet de volgende url;

http://www.shop.com/betalen.php?artikel=123&prijs=800

Goh, hoe zou je dit toch eens stevig kunnen misbruiken...

JIJ ziet dit, een computer ziet gewoon een string die met een GET commando wordt binnengehaald... even controleren of er geen code tussen zit, maar verder zal het wel veilig zijn (volgens de computer dan).

[Reactie gewijzigd door damnyankee op dinsdag 8 maart 2011 17:00]

Door W3ird_N3rd, dinsdag 8 maart 2011 17:42

Maar een computer kan in dit geval niet weten welke data een gebruiker aan mag passen.

Dat artikelnummer zo in de URL zetten is geen probleem. Dat mag de gebruiker ook best aanpassen, ik mag toch zelf weten welke fiets ik koop?

Alleen de prijs moet de server zelf adhv. het artikelnummer opzoeken. Die moet je niet door de gebruiker aan laten leveren: never trust user input.

Technisch gezien kan de URL die je laat zien best veilig zijn, het zal de fietsenboer alleen vast veel geld kosten. Stel echter dat dit zou gaan om de pay-what-you-want humble indie bundle of een donatiewebsite ipv. een fiets, dan zou dit weer perfect acceptabel zijn.

Ook met een "veilige" webshop kan je natuurlijk nog altijd de verkoper naaien. Bestel 5000 producten, of bestel iets zonder ooit te betalen. Geeft ook overlast.

Ander voorbeeld is denk ik beter, stel je hebt het volgende:

www.mailinglist.kom/nieuwsbrief.php?brief=maart&mailadres=003

Op de pagina kan je je eigen mailadres zien. Een computer zal hier waarschijnlijk geen kwaad in zien (het werkt toch prima en je hebt toch alleen je eigen nummertje?), maar je kan zo wel heel makkelijk mailadressen van de lijst gaan harvesten.

[Reactie gewijzigd door W3ird_N3rd op donderdag 10 maart 2011 01:32]

Door YDh, dinsdag 8 maart 2011 22:31

Een computer zal dit soort fout heus wel opmerken in zijn unit testing. Immers naast correcte waarden, wordt ook getest met foute waarden. Tijdens de testfase zou dit voorbeeld falen omdat het verwachte resultaat niet zou overeenkomen met het berekende resultaat.

Door CMG, woensdag 9 maart 2011 08:15

Dan moet er wel door een programmeur aan gedacht worden om een string met 1 miljoen karakters (of welke andere waarde dan ook groter dan de buffer van 80) te testen.

Ik kan me voorstellen dat men gedacht heeft: volgens de USB RFC mag een device naam niet langer dan 80 characters zijn. Als het volgens de USB standaard niet mag, dan hoeven we niet te controleren op een stituatie die niet voor kan komen.

Zeg niet dat het goed is, wel dat het begrijpelijk is.

Door BeosBeing, donderdag 10 maart 2011 16:46

Doet me denken aan de (1e) Ariane 5 die explodeerde omdat een variabele op nul stond. De de programmeur had die nul niet afgevangen omdat hij had bewezen dat die variabele nooit nul kon worden, althans op de Ariane 4.

Soms is het zinnig dingen af te vangen waarvan je weet/verwacht dat je niet kunnen gebeuren, alleen weet je nooit goed wanneer dat zinnig is of niet.

Door GamingZeUs, woensdag 9 maart 2011 00:15

Je zou ervoor kunnen zorgen dat alleen bepaalde GET waardes door de gebruiker mogen worden gegeven, een rechten systeem op variabelen.

Het bestaan van een URL zoals jij geeft is overigens nog steeds human error, aangezien een persoon het systeem zo gebouwd heeft dat de prijs een gebruikersvariabele is geworden.

Ach ja, gewoon geen stomme fouten maken (zoals een buffer overflow niet tegengaan).

Door Rizon, woensdag 9 maart 2011 07:38

Of je ai maakt geen links uit het jaar 1995 zoals een idiote mens wel nog zou doen...

Door daft_dutch, dinsdag 8 maart 2011 15:38

Als dit deel grondig volgens de beschikbare theorieen was getest dan had dit voorkomen moeten worden

Testen op Fout excepties binnen de white box test scoop. Welke theorie is dat?
Dit valt niet binnen de normale white box tests (bv Unit testen)
En met blackbox testen wordt je niet getriggerd op het strcpy-commando.

Alleen het reviewen van de code zal naar de mogelijke fout wijzen. Dat is geen Test theorie Dat is vrije tijd besteding.

BTW Dat een systeem zo zwak is als de zwakste schakel is flauwe kul. Dan zal alles wel een remote root vulnerability zijn

Door YDh, dinsdag 8 maart 2011 22:49

Testen op Fout excepties binnen de white box test scoop. Welke theorie is dat?
Dit valt niet binnen de normale white box tests (bv Unit testen)

Bij unit testing wordt wel degelijk ook ongeldige input voorgeschoteld aan de routine om te controleren dat de routine niets verkeerds doet. In het geval van een functie die een string uit een buffer kopieert zou er minstens testen moeten zijn die de volgende scenarios bevatten:

de string is null
de string is leeg
de string is te lang
de string bevat ongeldige karakters
...

Dat de gemiddelde programmeur zoiets niet doet maakt het niet minder fout.

Nu is het wel zo dat de meeste compilers al jaren uitgerust zijn met switches die buffer overruns detecteren at run-time en er voor zorgen dat ze niet misbruikt kunnen worden. Maar ja, dat soort checks introduceert natuurlijk altijd enige vorm van overhead, iets wat je natuurlijk niet wenst in kernel modules. En daarom is unit testing voor dit soort modules veel belangrijker dan voor gewone code.

Door Typnix, dinsdag 8 maart 2011 17:09

Nee, dit is geen human error. Als het een human error was geweest dan waren het andere soort fouten geweest dan het kiezen van een verkeerde functie. Het declareren van een strcopy is gewoon heel anders dan een strlcopy:

strcpy (str2,str1);

en

strlcpy(stack_buffer, source, sizeof(stack_buffer));

strlcopy is ook een relatief nieuwere functie(bestaat pas sinds OpenBSD-2.4) dan strcopy wat standaard in de ANSI C library geïmplementeerd zit.
Bron: http://en.wikipedia.org/wiki/Strlcpy

Ik durf te wedden dan ten tijde van het ontwikkelen van de driver de strlcopy functie niet algemeen bekend was onder ontwikkelaars.
En dat toen het wel zo was het niet zo grondig is doorgevoerd als men dacht. Dit zal hoogstwaarschijnlijk weer even ervoor zorgen dat men wat grondiger door de code gaat kijken.

[Reactie gewijzigd door Typnix op dinsdag 8 maart 2011 17:11]

Door SizzLorr, dinsdag 8 maart 2011 19:19

Tja zo heb je al jaren meerderen vraianten op strcpy. wstrcpy (welke ook widecharacters aan kan), strncpy, etc. etc. etc. noem ze maar op. Ze doen allemaal hetzelfde, het aantal characters beperken zodat je geen overflow kan krijgen.

Door mae-t.net, woensdag 9 maart 2011 00:26

En toch zijn zeker (heel ruwe schatting) de helft van alle bugs, ongeacht het OS, bufferoverflows. Kennelijk letten veel programmeurs niet op bij het vak "Programmeren 101" of bij het lezen van het boekje "C voor dummies".

Door zeduude, dinsdag 8 maart 2011 15:12

Linux haters?
bestaat dat?
mensen die linux niet kennen wel, maar haten?
vindt t wel cool, als je je pass vergeten bent op een systeem die je niet kan resetten, usb-(vast wel weer een arduino)-key d'r in en : root !!

..
bref.. de buffer overflows zijn de wereld nog niet uit...

edit: benadrukken (bold) van wat ik schreef...

[Reactie gewijzigd door zeduude op woensdag 9 maart 2011 08:32]

Door ]Byte[, dinsdag 8 maart 2011 15:29

Euhhh... booten in single-user mode en pw veranderen is ook een oplossing....

Door wica, dinsdag 8 maart 2011 16:16

Euhhh, booten naar single-user mode, vraagt tegenwoordig ook om het root wachtwoord.

Booten van een live cd / usb en dan het wachtwoord aanpassen.

Vanuit gaande dat je de boot volgorde zou kunnen aanpassen

Door johnkeates, dinsdag 8 maart 2011 17:09

Precies. Als je nog een CMOS / Legacy BIOS systeem hebt kan je dat ook omzeilen met 1 enkele instructie, maar met OpenFirmware of Extended Firmware Interface wordt dat al een stuk moeilijker. En dan is er nog OpenBios en Coreboot waar het helemaal lastig is.

Uiteindelijk hebben we het hier over een exploit die fysieke toegang vereist, en dat is dan helaas een stuk minder specaal. Met fysieke toegang is alles te hacken. Ook bitlocker kan je er heel eenvoudig mee breken.

Door daft_dutch, dinsdag 8 maart 2011 17:10

en dat de disk niet encrypted is.

Door SizzLorr, dinsdag 8 maart 2011 19:22

En dat de gewensten poorten/drives aanwezig zijn. Ik zie steeds vaker dat computers de intellingen hebben om USB mass storage te weigeren en de BIOS ongeautoriseerde drives/kaarten niet accepteert. Kwam dat pas tegen in een HP workstation, die weigert keihard kaarten die niet op de HP whitelist staan.

[Reactie gewijzigd door SizzLorr op dinsdag 8 maart 2011 19:23]

Door rob12424, dinsdag 8 maart 2011 19:28

Dat kan tot dat je zoals ik de groepen hebt aangepast en dan per ongeluk je zelf hebt buiten gesloten (dat is mij 1x overkomen!) Gelukkig is er dan nog 1 weeg en dat is via de grub command line (mits je daar ook geen wachtwoord op hebt gezet!

)

Oke het was dom maar wel leerzaam!

Door jbcn, dinsdag 8 maart 2011 23:23

Euhhh, kom je gemakkelijk omheen door even "init=/bin/bash" als parameter mee te geven

Door iMars, dinsdag 8 maart 2011 15:33

Op zich wel handig, maar het gaat alleen bij systemen met een 'oude' kernel.

Het onveilige strcpy-commando werd pas in februari vervangen door het veiligere strlcpy-commando in de Linux-kernel.

Als je een nieuwere kernel hebt, zou het dus niet meer mogelijk moeten zijn...

Bewijst maar weer dat je altijd up-2-date moet zijn

Door thechronic, woensdag 9 maart 2011 21:09

Dit viel me ook op, ze vinden nu een veiligheidsprobleem dat een maand geleden al opgelost is.

Zo kan ik ook wel veiligheidsfouten ontdekken door in changelogs te gaan speuren

Door mrlammers, dinsdag 8 maart 2011 15:36

Stel dat je via USB toegang zou krijgen op kernel niveau, het geeft jou dan dus (nog) geen rootrechten...

Door MSalters, dinsdag 8 maart 2011 23:38

Op het moment dat je kernel-level access hebt, heb je alle rechten. Je kunt alle geheugen, inclusief alle security-gerelateerde code en data lezen en schrijven.

Door mrlammers, woensdag 9 maart 2011 13:08

Dat zou te makkelijk zijn. Een USB apparaat krijgt door de driver automatisch kernel-level access (I/O), maar dat betekent niet dat je als USB interfacegebruiker super user rechten hebt.
Mensen beseffen zich niet voldoende dat automatisch mounten van apparaten een groot veiligheidsrisico met zich meebrengt. Het hele circus kun je volgens mij omzeilen door de automount voor USB apparaten in fstab uit te zetten. Dit verhindert shell/user level access. Probleem opgelost.
Of je verwijdert de betrokken drivers: . /sound/usb/caiaq/audio.c en ./sound/usb/caiaq/midi.c
Probleem opgelost.

Door Dreamvoid, dinsdag 8 maart 2011 16:32

Linux haters?
bestaat dat?
mensen die linux niet kennen wel, maar haten?

Puristen die een hekel hebben aan monolitische kernels?

Door DevilsProphet, dinsdag 8 maart 2011 16:53

Buiten A. S. Tanenbaum waarschijnlijk niemand.

Door TRRoads, dinsdag 8 maart 2011 22:00

Linux en monolitische kernel hoeft niet synoniem te zijn natuurlijk. De "Everything as a module" mentaliteit zit er toch bij menig distro wel in.

Door snirpsnirp, dinsdag 8 maart 2011 23:38

Een beetje purist zou een hekel hebben aan hybride kernels of microkernels...

Door BeosBeing, donderdag 10 maart 2011 16:52

Linux haters?
bestaat dat?
mensen die linux niet kennen wel, maar haten?

Ja, er zitten er zelf een paar op Tweakers.net.
Ik ga maar geen namen noemen ;')

[Reactie gewijzigd door BeosBeing op donderdag 10 maart 2011 16:53]

Door Zunflappie, dinsdag 8 maart 2011 15:56

Gelukkig is er de nieuwe functie strlcpy() al... dus bij genoeg updates/patches is dit al verholpen. Toch?

Door _JGC_, dinsdag 8 maart 2011 17:25

Mja, wees maar gerust, dit soort dingen gaan veel vaker voorkomen. Punt is alleen... deze bugs zijn zwaar overtrokken. Bij de gemiddelde linux (en ook windows en OS X) install kan je met fysieke toegang tot het systeem sowieso wel Administrator of root krijgen. Om deze bugs te exploiten heb je fysieke toegang nodig, en dan nog vraag ik me af of het niet veel makkelijker is om gewoon de CMOS te clearen, van CD te booten en het rootpassword te veranderen.

Door brabbelaar, dinsdag 8 maart 2011 17:34

Zeer mee eens.

Met fysieke toegang kan je vrijwel elk systeem binnenkomen. Dat maakt dit soort bugs niet goed, maar 'een groot gevaar' is het niet bepaald te noemen. Vooral omdat - in tegenstelling tot wat het artikel beweert - dit in de meeste kernels die in omloop zijn wel gerepareerd is.

Het vinden en patchen van bugs zal hopelijk nog veel vaker voorkomen. Voordeel van linux is dat dit patchen doorgaans zeer snel gebeurt.

Door The_Double, dinsdag 8 maart 2011 18:38

Maar je heb hier helemaal geen fysieke toegang nodig. Denk maar aan een eBay merchant die usb sticks verkoopt. Die kan dan mooi toegang krijgen tot alle linux pcs waar die stickjes in worden gebruikt.

Door rvannieuwpoort, dinsdag 8 maart 2011 20:05

Precies. Zo was Stuxnet toch ook die kerncentrales in Iran binnengedrongen? Via besmette USB sticks?

Door SuperDre, dinsdag 8 maart 2011 20:11

Door onox, woensdag 9 maart 2011 02:18

De C haters

Door Cyberslak, dinsdag 8 maart 2011 14:43

Aardig om te zien dat de steeds populairder wordende Linux-besturingssysteem die toch bekend staat als betrouwbaar ook de nodige lekken heeft.

Nu is dit weer een probleem waarbij je direct toegang moet kunnen krijgen tot de machine.
Wat bij bijv. een server normaal gesproken niet zomaar kan.

Door Oeroeg, dinsdag 8 maart 2011 14:48

De vraag is of je dit als een lek kunt beschouwen.
Je moet immer fysieke toegang tot de machine hebben, en als je dat al hebt, dan is het meestal ook niet zo moeilijk om in een recovery modus als root op te starten.

Door Neverwinterx, dinsdag 8 maart 2011 14:50

Je hoeft geen fysieke toegang te hebben, enkel een USB device met een lange devicenaam hoef je te verspreiden. Wat natuurlijk niet zo makkelijk is. Als je de naam van bestaande devices kan veranderen, dan zou het pas echt gevaarlijk worden.

[Reactie gewijzigd door Neverwinterx op dinsdag 8 maart 2011 14:51]

Door MRammeloo, dinsdag 8 maart 2011 15:25

Ach, een 'relatiegeschenkje' op de juiste plek uitdelen...

Door johnkeates, dinsdag 8 maart 2011 17:10

Dus jij steekt alles wat je binnenkrijgt in productie platformen? Dat heeft nog steeds een human error of een PEBCAK.

Door brabbelaar, dinsdag 8 maart 2011 17:36

tja, als ik op een beurs of congres een usb-sticky krijg dan zou ik die wel in m'n laptop duwen om te kijken wat het is ja. Ik heb een virusscanner, ik draai linux... draaide ik windows dan deed ik dat ook.

Er zijn wel eens virussen op nieuw verkochte harde schijven aangetroffen, wat wil je dan? Nooit nieuwe hardware gebruiken?

Door TRRoads, dinsdag 8 maart 2011 22:05

Paranoid much?

Door mae-t.net, woensdag 9 maart 2011 00:31

Realistisch. Zo'n ding onbeschermd ergens in steken is nog nooit een goed plan geweest, en dat mag langzaamaan toch wel een beetje publiekelijk bekend zijn.

Onder windows was het al tijden een slecht plan vanwege het "bericht bij automatisch invoegen", dat onder XP inmiddels naar verluid uitgezet is middels een patch, en wegens mogelijke bufferoverflows en onder linux dus vooral vanwege dat laatste. En als dat dan geen probleem is kan er natuurlijk altijd een trojan op staan.

[Reactie gewijzigd door mae-t.net op woensdag 9 maart 2011 20:45]

Door humbug, dinsdag 8 maart 2011 14:56

Kom kom, lek is lek. Zoals de onderzoeker al zegt "Linux plug&pwn" Tijdens je bezoek aan het datacenter even zo'n apparaat in verschillende servers stoppen is niet heel moeilijk. Dat er ook andere manieren zijn, tsja. Dat is bij de discussies over veiligheidsgaten in Windows ook nooit een probleem

Linux heeft net zoals OS/X of Windows gewoon een hoop veiigheidsgaten. Soms is het pure onkunde maar veel vaker is het een gevalletje pech hebben. Je kan nu eenmaal niet alles dichttimmeren. Wel is het nu zaak om de driver snel te vervangen zodat ook dit lek weer snel gedicht is.

Door LollieStick, dinsdag 8 maart 2011 15:00

Het lek is al gedicht

(zie artikel)

Door MicGlou, dinsdag 8 maart 2011 15:21

Het lek is al gedicht in de kernel, maar of deze kernel al breed is uitgerold in de verschillende builds die daarvan bestaan? Dat is wat het artikel ook vermeld en dat is dus verre van... de meeste builds draaien namelijk nog de oude verkeerde driver.

Desondanks zouden er nog talloze kwetsbare Linux-kernels in omloop zijn, mede doordat vrijwel alle distro's gebruikmaken van de Caiaq-usb-driver.

Door LollieStick, dinsdag 8 maart 2011 15:40

Wel is het nu zaak om de driver snel te vervangen zodat ook dit lek weer snel gedicht is.

Dat was het puntje waarop ik reageerde. De kernel-maintainers hebben hun werk gedaan, nu is het de taak van de distro-bouwers of de HTK-kernelbakkers om hun kernel te updaten.

Door thechronic, woensdag 9 maart 2011 21:13

Iedere distro die zijn naam waardig is backport veiligheidsfixes naar de huidig ondersteunde platformen, en niet enkel voor de kernel, maar voor alle software in de repositories.

Door BeosBeing, donderdag 10 maart 2011 16:59

Alleen zou het zinnig zijn geweest om te vermelden vanaf welke kernel het gedicht is. Er staat geen versienummer vermeld.

Door lenny_z, dinsdag 8 maart 2011 15:19

Kom kom, lek is lek. Zoals de onderzoeker al zegt "Linux plug&pwn" Tijdens je bezoek aan het datacenter even zo'n apparaat in verschillende servers stoppen is niet heel moeilijk

Lek is inderdaad lek.
Maar een datacenter kom je ook niet zomaar in he...
De centra die ik heb bezocht waren in ieder geval allemaal beveiligd met toegangspoortjes, camera's, etc.

Door Sorcerer8472, dinsdag 8 maart 2011 15:42

Bovendien zitten de meeste racks dicht met sloten in gedeelde suites, en is er camerabeveiliging... dus als je al legaal binnenkomt kun je niet zomaar bij alle apparatuur.

Overigens zijn er andere OS'en waar je sowieso al makkelijk via USB virussen e.d. kunt verspreiden (iets met autorun, verder zeg ik niets

)

Door iMars, dinsdag 8 maart 2011 15:37

@humbug && lenny_z: Tenzij USB uitstaat op de server. Ik gebruik geen USB op mijn server, en staat in de bios uit

Door thegve, dinsdag 8 maart 2011 16:16

Gebruik je dan ps/2 toetsenborden? Nieuwere servers hebben geeneens ps/2 poorten meer.

Door IoorLTD, dinsdag 8 maart 2011 16:30

raar dat 99% van jouw nieuwere servers toch een ps2 gat achterin hebben... of kijk je daar nooit?

Door FreshMaker, dinsdag 8 maart 2011 17:37

Mijn server geeft in het bios een optie, selctief in / uitschakelen
en type om in te pluggen

als ik kb/mouse heb, werkt een ander apparaat er niet op, zelfs een IR infrarood receiver doet het niet ..

Door thegve, woensdag 9 maart 2011 11:07

http://www.dell.com/us/business/p/poweredge-t610/pd

Zoekt en gij zult niet vinden!

En zijn platgestampte broertje mocht je het over rack-servers hebben:
http://www.dell.com/us/business/p/poweredge-r610/pd

Heeft hem ook niet.

Wij hebben ongeveer 50-75 R610's bij klanten uit staan, en nog meer oudere types die hem ook al niet meer hebben.

Volgens mij (maar dat weet ik niet zeker), had zelfs de 1900 al geen ps/2 meer, en dat is er een van jaren oud:
http://reviews.cnet.com/s...1707-3125_7-32490746.html

Maar daar kan ik me heel goed in vergissen, niet zo vaak meer in mijn handen gehad (en de hardware hoek is verder ook niet mijn natuurlijke habitat)

edit:
HP heeft nog wel een PS/2 poort zie ik:
http://h18004.www1.hp.com...cs/13241_na/13241_na.html

[Reactie gewijzigd door thegve op woensdag 9 maart 2011 11:27]

Door Carharttguy, dinsdag 8 maart 2011 16:31

Gebruik je dan ps/2 toetsenborden? Nieuwere servers hebben geeneens ps/2 poorten meer.

wat dacht je van remote control, SSH bijvoorbeeld?
Ik zie mezelf nog geen toetsenbord/printer/alle-andere-apparaten-op-usb aansluiten op m'n server.

Door MadEgg, dinsdag 8 maart 2011 16:42

Als ik voor maintenance in het datecentrum kom, bijvoorbeeld om een reepje geheugen te vervangen, dan sluit ik doorgaans wel een monitor en toetsenbord erop aan ja; wel fijn als ik direct kan controleren of alles goed gegaan is.

Door thegve, woensdag 9 maart 2011 11:09

Wat dacht je van installatie, upgrade van server, etc. Is niet allemaal practisch via SSH. Als hij eenmaal op zijn plek staat zijn werk te doen dan uiteraard via SSH (alleen al omdat er dan ook 100+ kilometer tussen mij en de server zit).

Door kidde, dinsdag 8 maart 2011 20:55

Tijdens je bezoek aan het datacenter even zo'n apparaat in verschillende servers stoppen is niet heel moeilijk.

Leuk leuk hoor, maar hoeveel servers hebben ondersteuning voor USB-sound? Als het goed is praktisch geen één, want ik ga ervan uit dat een beetje server-admin de kernel aanpast voor de bak waar dat ding op draait.

Ik wel voor m'n desktoppie, en nee, die heeft geen USB-sound ondersteuning.

Dus nee, je kan niet alles dichttimmeren, maar in Linux kan je wel eenvoudig de troep weglaten die je niet nodig hebt. Eenvoudiger dan in sommige andere kernels, lijkt me.

Natuurlijk is er in Linux een nogal groot beveiligingsprobleem omdat er geen 'capability based security' is (zoals A. Tanenbaum altijd graag uitlegt), dat dan weer wel. Want had dat in Linux gezeten, dan was het risico / gevolg van het uitbuiten van dit lek veel beperkter geweest. Maar ja, dat is al jaren bekend, en helaas zijn er weinig kernels die dit probleem verhelpen.

Door Emmef, dinsdag 8 maart 2011 22:20

Het leuke is dat het capability systeem wel is (zie SELinux), maar slechts wordt gebruikt voor een klein aantal zaken (zoals realtime scheduling permissies) en dan nog via PAM modules. Je kunt het ook hard in je filesysteem opnemen en per proces de capabilities instellen (inclusief wat er te erven is naar sub-processesn) maar de meeste programma-makers en distros hebben hier geen zin in.
Zo kan een web server die draait onder een andere user dan root best onder poort 1024 draaien (wat normaal alleen root mag) door een attribuut op te nemen voor de executable. Maar als je dan ook oudere bestandssystemen wilt ondersteunen werkt dat niet, want die ondersteunen de extra attributen niet. Tja: en dan moet je weer twee scenario's gaan bijhouden.

[Reactie gewijzigd door Emmef op dinsdag 8 maart 2011 22:20]

Door bzerk, woensdag 9 maart 2011 13:47

Klok en klepel?
Je kunt inderdaad dmv SELinux een executable of een user het recht geven privileged ports beneden 1024 te openen. Dit heeft echter helemaal niets met het gebruikte bestandssysteem te maken.
Jij bent in de war met Extended Attributes.

Door Jeroen, dinsdag 8 maart 2011 15:10

Voor mensen die hun computers wel goed beveiligen is dit wel degelijk een lek.

Door arjankoole, dinsdag 8 maart 2011 15:15

Voor mensen die hun computers wel goed beveiligen is dit wel degelijk een lek.

Nee, want die mensen hebben hun USB poorten uitgezet, en draaien bovendien een al lang en breed gepatchte kernel.

Door _JGC_, dinsdag 8 maart 2011 17:28

Mwah, fix is net een dag uit. Ik heb gisteren nog nieuwe kernels uitgerold op een aantal testservers, en daar zat deze fix niet in. Releasedatum van die nieuwe kernels was afgelopen zaterdag (2.6.32.31, vannacht .32 gereleased dus).
Maargoed, in mijn servers mag je gerust een USB stick steken die zich voordoet als een geluidskaart, de kernels die ik draai weten niet eens wat USB is, laat staan dat ze drivers voor een vage geluidskaart voeren.

edit:
fixes die vandaag uit zijn gekomen fixen een soortgelijke bug in een andere driver, maar daarbij wordt vermeld dat het zeer onwaarschijnlijk is dat het te gebruiken is.

[Reactie gewijzigd door _JGC_ op dinsdag 8 maart 2011 21:00]

Door bbc, dinsdag 8 maart 2011 14:50

Ik krijg bijna dagelijks mails binnen over security lekken via de debian security mailing list. Dat maakt een distro niet meer of minder betrouwbaar. Het toont enkel aan dat er aan oplossingen gewerkt wordt.
Dit is gewoon slechte code, waarvoor nu een fix gemaakt wordt. Op servers loop je niet al teveel risico. Als een onbevoegde fysiek toegang heeft tot je toestellen, is zo een usb stick in mijn ogen niet je eerste zorg.
Het is goed dat de aandacht op deze bug wordt gevestigd, maar dat is het dan ook.

Door worldcitizen, dinsdag 8 maart 2011 16:56

Dit is gewoon slechte code, waarvoor nu een fix gemaakt wordt. Op servers loop je niet al teveel risico. Als een onbevoegde fysiek toegang heeft tot je toestellen, is zo een usb stick in mijn ogen niet je eerste zorg.

Dit hoeft helemaal geen slechte code te zijn, er is iets over het hoofd gezien.

Er is bij geen enkel systeem geen probleem meer als je maar de patches installeert en een gesupporte Linux distro versie gebruikt.

Zie de fix.

De fix is van 16 Februari.
Tweakers/labs.mwrinfosecurity.com als je al nieuws hebt kom dan met iets wat meer up to date is.

Wat me iedere keer opvalt is dat Linux bugs meestal al gefixed zijn wanneer het nieuws naar buiten komt, in tegen stelling to veel commerciële OSen.

Zoals de eerder vermelde Linux bug (staat ook in de post): nieuws: Aanval met usb-disk kan ook onder Linux

[Reactie gewijzigd door worldcitizen op dinsdag 8 maart 2011 23:00]

Door xbm360, dinsdag 8 maart 2011 16:58

Ik weet niet of die code nou zo enorm slecht is. Een soort-gelijke bug had de PS3 ook, waardoor via USB ook 'n exploit openbaar werd.

Dit soort bugs zullen bij ieder systeem voorkomen, alleen moet maar net 'n slimmerik 't proberen uit te buiten.

Door _JGC_, dinsdag 8 maart 2011 21:03

Mja, die mails die je van Debian binnenkrijgt zijn ook nogal gevarieerd, vaak gebruik je de software niet eens of staat het gewoon helemaal niet op het systeem. Wat ik minder leuk vind is dat er sporadisch kernel updates zijn, en als ze er zijn, fixen die dingen meteen 10-20 openstaande CVE's. IMHO wil je zo snel mogelijk na de bekendmaking van zo'n bug een gefixt pakket uitbrengen ipv dat je zoiets opspaart tot je er 20 hebt.

Door Patriot, dinsdag 8 maart 2011 15:15

Aardig om te zien dat de steeds populairder wordende Linux-besturingssysteem die toch bekend staat als betrouwbaar ook de nodige lekken heeft.

Nu is dit weer een probleem waarbij je direct toegang moet kunnen krijgen tot de machine.
Wat bij bijv. een server normaal gesproken niet zomaar kan.

Wat vind je daar precies aardig aan? Ik denk namelijk dat je vermoed dat dit aangeeft dat Linux minder betrouwbaar is dan zoals het bekend staat, dat is echter niet het geval. Juist door dit soort mensen komen deze bugs aan het licht en worden ze verholpen, zo kan er geen misbruik (meer) van gemaakt worden.

Door magicsam, dinsdag 8 maart 2011 15:54

Ook best aardig dat de bug al gefixed is ten tijde van dit nieuwsbericht!

Door backspace219, dinsdag 8 maart 2011 16:12

Aardig om te zien dat de steeds populairder wordende Linux-besturingssysteem die toch bekend staat als betrouwbaar ook de nodige lekken heeft.

Niemand heeft ooit gezegd dat Linux bug/lek vrij is, maar vergeleken met de concurrentie kun je hem wel als 'betrouwbaar' aanmerken.

Door Countess, dinsdag 8 maart 2011 18:11

met fysieke toegang is elke Windows machine over te nemen.

bij Windows is het een feature dat je met een boot cd het wachtwoord kan resetten en zo
toegang kan krijgen, bij linux is het een bug.

Door Skinkie, dinsdag 8 maart 2011 19:53

init=/bin/sh
mount -o remount,rw /
passwd

...je punt is?

Door bzerk, woensdag 9 maart 2011 14:01

Dat kan alleen als je geen password op de bootloader (meestal grub) zet. Booten van CD kun je uiteraard in de BIOS uitzetten.
Met deze maatregelen voorkom je dat iemand met "virtuele fysieke toegang" (via ILO of DRAC) de computer over kan nemen.
Tegen werkelijke fysieke toegang (BIOS batterij shorten, disks overzetten in ander systeem) is het bijna onmogelijk je te wapenen.

Door djexplo, dinsdag 8 maart 2011 14:44

Tijd om de hele linux-source eens te porten naar D of Cyclone, dan heb je in 1x alle code beschermt tegen buffer-overflows ten koste van een klein stukje performance.
http://en.wikipedia.org/w...28programming_language%29
Een OS die dit al heeft gedaan:
http://en.wikipedia.org/wiki/AuroraUX

[Reactie gewijzigd door djexplo op dinsdag 8 maart 2011 14:48]

Door FireDrunk, dinsdag 8 maart 2011 14:51

Cyclone attempts to avoid some of the common pitfalls of C, while still maintaining its look and performance. To this end, Cyclone places the following limits on programs:

NULL checks are inserted to prevent segmentation faults
Pointer arithmetic is limited
Pointers must be initialized before use (this is enforced by definite assignment analysis)

En dus crashen de programma's ipv dat ze misschien onveilig zijn...

Leuk voor je printertje thuis die je wil aansluiten, en je os zegt, kernel panic: "Weet je wat, dikke vinger met je printer!, ik ga uit!"

[Reactie gewijzigd door FireDrunk op dinsdag 8 maart 2011 14:51]

Door PPie, dinsdag 8 maart 2011 15:30

En is dat beter dan een buffer overflow, daarmee je disk driver corrupten en dan enige tijd later je de data op je HD verknallen?

Door tweakerbee, dinsdag 8 maart 2011 15:47

Het is ook niet voor je thuis PC, maar voor die belangrijke server. En ja, die kan er beter met kernel panic uitknallen dan compromised zijn.

Door kidde, dinsdag 8 maart 2011 21:03

Aha, kijk, en daar is Minux voor: Dan kan een kernelmodule duizenden keren crashen (omdat de code random verandert) en draait de kernel gewoon door

Want tja, een auto stopt toch ook niet met rijden als de verwarming kapot is? Linux helaas wel als een driver zuigt. Maar het is wel de meest werkbare oplossing op dit moment natuurlijk. Toch hoop ik dat Minix en consorten een lans breken om de 'binneste kernel' te beschermen tegen drivers, want ook uit dit voorbeeld van 'caiaq' blijkt maar weer dat 80% van de uitbaatbare kernel-fouten in drivers zitten (is ook bij Windows schijnt).

Door tweakerbee, dinsdag 8 maart 2011 22:00

Bij Windows draaien veel drivers ook al niet meer helemaal in kernel space. Bijvoorbeeld een display driver volgens WDDM kan rustig crashen. Je scherm wordt even zwart terwijl de driver herstart, maar daarna kun je gewoon verder werken.

Door Antipater, dinsdag 8 maart 2011 18:10

Ja, dit is wel les 1 in stabiele programma's schrijven: als je een bug constateert moet je onmiddelijk crashen, geen excuses. Niet crashen betekent: anything goes.

Stabiel programma + usb bug: dikke vinger ik ga uit. Jammer, reboot en dag met je stick, verder niets aan de hand.

Onstabiel programma + usb bug: werkt lekker door en formatteert onderstussen al je harddisks...

Door mae-t.net, woensdag 9 maart 2011 00:35

Je hoeft niet te crashen, je OS kan gewoon dat programma afschieten en verder gaan. Uitgaande van een beschermd geheugenmodel natuurlijk, zie ook DEP onder Windows (zit in de modernere processoren ook gewoon hardwareondersteuning voor dacht ik toch).

[Reactie gewijzigd door mae-t.net op woensdag 9 maart 2011 00:36]

Door bzerk, woensdag 9 maart 2011 14:07

Het programma is in dit geval de kernel zelf. Dus wel degelijk een crash (panic).

Door Cyw00d, woensdag 9 maart 2011 08:59

Was de wereld maar zo zwart-wit, heb jij die hele Wiki pagina wel gelezen?
Ik citeer van de Cyclone Wiki:
[quote]
This tells the Cyclone compiler that the argument to foo should never be NULL, avoiding the aforementioned undefined behavior. The simple change of * to @ saves the programmer from having to write NULL checks and the operating system from having to trap NULL pointer dereferences...
[quote]

Oftewel Cyclone introduceert een nog strengere C-compiler, zodat je tijdens compilen meer fouten op je bord krijgt die anders in latere versies als bug worden afgedaan.
Je hebt gelijk dat door bounds-checking de hele applicatie kan crashen als hij deze fout detecteerd, maar dat heeft 2 voordelen:
- Je loopt geen geheugen te veranderen waar je niet mag zijn. Waardoor je applicatie gedrag gaat vertonen die onverklaarbaar is.
- Je kan je applicatie nog sneller verbeteren (debuggen)

Door Dreamvoid, dinsdag 8 maart 2011 15:17

Daarom ook sturen OS bouwers de applicatiedevs langzaam aan richting managed code omgevingen als Java/Dalvik/.NET/LLVM/Air/etc, waar je geen buffer en stack overflows meer hebt.

[Reactie gewijzigd door Dreamvoid op dinsdag 8 maart 2011 16:28]

Door kidde, dinsdag 8 maart 2011 21:04

Wel een beetje oldschool, die 'high level languages': Laatste OS dat in high level was, was de voorloper van UNIX vziw. Wel lachen, dat zoiets dan toch na ~50 jaar weer terug komt!

Door FastFred, dinsdag 8 maart 2011 14:44

Nu moeten linux gebruikers ook aan de antivirus!

Door JapyDooge, dinsdag 8 maart 2011 14:47

Ik zie niet in wat een antivirus aan een brakke driver en een fysieke usbstick doet hoor.

Door Toettoetdaan, dinsdag 8 maart 2011 14:47

Door Oeroeg, dinsdag 8 maart 2011 14:50

Een fysiek slot op je USB-poort?

Door Blokker_1999, dinsdag 8 maart 2011 14:57

Elke slimme gebruiker heeft op al zijn systemen een AV staan.

Door DikkeDouwe, dinsdag 8 maart 2011 15:14

Door lenny_z, dinsdag 8 maart 2011 15:35

mwah... ik niet. Ik haat anti-virus software, ze maken je machine bloated.

Ik heb thuis een zeer scherp afgestelde firewall, op elke PC browsers in een sandbox en maar 1 persoon met rechten om applicaties te installeren (c'est moi!

)

Das niet 100%, maar behoorlijk veilig, ik heb al jaren geen virussen meer gehad.
(en ja ik scan de boel wel eens per maand, maar heb geen standaard anti virus suite draaien)

Door backspace219, dinsdag 8 maart 2011 16:13

Door hackerhater, woensdag 9 maart 2011 10:24

En zelfs als het onder WINE zou werken kan je het zo afschieten gezien WINE een user-process is. En automatisch opstarten met de machine zal nooit werken

Door Benne, dinsdag 8 maart 2011 16:44

Door Shepard, dinsdag 8 maart 2011 14:59

Inderdaad. Geen enkel OS is 100% veilig uiteraard.

Door blouweKip, woensdag 9 maart 2011 02:04

Gelukkig blijft het over het algemeen bij zit soort exploits, en kun je er (itt tot commerciele operating systems) zelf wat tegen doen.
Maar idd, mensen die denken dat er 100% onfeilbare software is die hebben oogkleppen op.

Door ChaoZero, dinsdag 8 maart 2011 14:59

euhm, nou, nee.

Nog voordat er iets gescanned kan worden (dus tijdens de initialisatie van de drive, direct na het aansluiten) is deze buffer-overflow al gebeurt. Om de scan uit te laten voeren moet er een 'te scannen locatie' worden ingevoerd.

Als deze locatie te vinden is in het systeem, is de schijf dus al geinitialiseerd (nieteens gemount!) en het lek reeds misbruikt. In andere woorden: de scan engine is afhankelijk van de Caiaq-usb-driver-module.

nog kort over windows vs linux:
Zowel Windows als linux (als ook OSX) hebben deze probleempjes (lees: buffer-overflow-vulnerabilities). Kijk bijvoorbeeld naar de bug in de rpc-service in windows (het hele conficker-verhaal).
Het mooie van opensource is echter dat deze bugs makkelijk gevonden, aangetoond en verholpen kunnen worden. In closed-source programmatuur is het in de code rondneuzen naar foutjes natuurlijk minder makkelijk, en dergelijke bugs worden dan ook minder snel ontdekt.

apt-get update && apt-get upgrade had dit probleem al in februari (voordat het hier in het nieuws kwam) verholpen. clamav is (bij mij) dus nog steeds alleen nodig voor emails en data voor windows-gebruikers

[Reactie gewijzigd door ChaoZero op dinsdag 8 maart 2011 15:03]

Door lenny_z, dinsdag 8 maart 2011 15:21

Het mooie van opensource is echter dat deze bugs makkelijk gevonden, aangetoond en verholpen kunnen worden.

Jaja, maar het mes snijdt wel aan 2 kanten vriend:
re-phrase:

Het mooie van opensource is echter dat deze exploits makkelijk gevonden kunnen worden, je kan de code immers zo inkijken!

Door thechronic, woensdag 9 maart 2011 21:22

Ja dat denken wel meer mensen. Maar in de praktijk zie je dat veiligheidsproblemen in Linux veel sneller gevonden en verholpen worden.

Door 84hannes, dinsdag 8 maart 2011 15:10

Dus in plaats van de nieuwe updates te installeren installeren adviseer jij een programma op je PC te draaien dat bij elke bewerkign controleert op vooral bekende veiligheidslekken. Lijkt me geen succes voor de performance.

Door kidde, dinsdag 8 maart 2011 21:07

Tja, ik weet het idd niet; er is een reden dat er in vliegtuigen geen airbags zitten! En al helemaal dat die er niet los bij de ingang bij verkocht worden.

Door Robtimus, dinsdag 8 maart 2011 14:45

Dit is toch wel een basic programmeerfout zeg. strcpy errors komen al jaren voor, je zou toch denken dat men al sinds de eerste strcpy gerelateerde bug zou zijn overgestapt op varianten als deze strlcpy of strncpy?

Door sfranken, dinsdag 8 maart 2011 14:50

Is men inmiddels ook, kernel 2.6.38 gebruikt stricpy

Door LollieStick, woensdag 9 maart 2011 08:41

De bug is gefixed vanaf 2.6.37.2. Alle voorgaande versies zijn vatbaar. Het is dus inderdaad vanzelfsprekend dat 2.6.38 niet vatbaar is, maar deze is nog niet stable.

2.6.37.2 is wel stable en is dus de eerste stabiele versie die dit probleem niet heeft.

Door humbug, dinsdag 8 maart 2011 14:58

Wat raar dat jij die basis programmeer fout dan niet eventjes uit de complete Linux code hebt gehaald.... Search en replace toch?

Door .oisyn, dinsdag 8 maart 2011 16:46

Nou is het wel iets ingewikkelders dan dat (je moet immers ook een lengte meegeven, dat moest voorheen niet), maar IceManX heeft gewoon gelijk - dit ís een basis programmeerfout. En waarom is hij verwantwoordelijk voor de fixes in linux code? Hij zal wel wat beters te doen hebben.

Door Robtimus, dinsdag 8 maart 2011 17:59

Ik zeg niet dat het snel op te lossen is, maar wel dat elk stuk software dat zeg maar de afgelopen 3 jaar uitgebracht is op de hoogte moet zijn van de problemen die strcpy (en zo nog een aantal functies) oplevert. En dat betekent dus dat in principe iedereen zijn eigen code allang gefixt zou moeten hebben - niet van de een op de andere dag, maar buffer overflow errors zijn al behoorlijk oud, en toch blijven een aantal programmeurs er niet op controleren. Dat is een kwalijke zaak.

En zoals .oisyn al zegt is search en replace niet zo eenvoudig, maar een eenvoudige search wel degelijk (find + grep = resultaat). Daarna is het helaas handmatig regel voor regel fixen, vanwege de length parameter.

Door _JGC_, dinsdag 8 maart 2011 23:45

GCC geeft iig al een warning als je nu nog strcpy gebruikt, maargoed... wie bekijkt tegenwoordig nou warnings? Weet niet of je wel eens iets als Firefox of OpenOffice gecompileerd hebt, maar welke compiler je ook probeert, die pakketten gaan echt niet compilen met -Werror in de CFLAGS.

Door stitch23, dinsdag 8 maart 2011 15:09

sorry hoor, maar als je al fysiek toegang hebt is een standaard machine al practisch weerloos. Daarom, bij server hardening hoort ook het dichtgooien van usb/cd etc.

Door lenny_z, dinsdag 8 maart 2011 15:28

Daar ben ik het dus in de meeste gevallen niet mee eens.
Hoe ver moet je gaan met server hardening?

USB standaard dichtzetten. De kans dat je er alleen maar hinder van gaat ondervinden is zo levensgroot...tegenover een uiterst miniem veiligheids voordeel.....van dat er misschien ooit een exploit zou kunnen zijn voor een device die niet van buiten af is te benaderen.

Daarbij, van de week moest ik nog een dongle installeren in een server. Via USB dus.
Leuk als jij die dan had uitgezet.

Je kan oneindig doorgaan met beveiligen.
Op een gegeven moment moet je een balans vinden tussen werkbaar en "veilig genoeg". En hoe veilig iets moet zijn, dat is wel afhankelijk van de data.
Zo kan ik me indenken dat de eisen aan een transactie server voor een bank alles op alles wil stellen en in dat geval is bijna geen enkele beveiliging te gek.

[Reactie gewijzigd door lenny_z op dinsdag 8 maart 2011 15:36]

Door kidde, dinsdag 8 maart 2011 21:09

Nogmaals, fout zit in USB sound, niet in USB! Zoek je kernel source er maar op na.

(/usr/src/linux/sound/usb/caiaq, maar svp. niet aan Linus vertellen, die krijgt een hartaanval als die hoort dat mensen hem nog steeds in /usr zetten!)

Beetje slordig van Tweakers lijkt me.

Door PPie, dinsdag 8 maart 2011 15:32

het dichtgooien van usb/cd etc

Waarom zou je dat doen? Als de persoon al bij de machine staat, ben je toch al verloren...
Nu maak je het alleen maar moeilijk voor de legitieme support mensen.

Door buzzin, dinsdag 8 maart 2011 16:39

Een echte server hangt in een afgesloten ruimte met als last resort een slot op rack, server en KVM paneel.
Als een inbreker zo ver is als de USB poort = Machine is verloren.

Het aflsuiten van USB/CD is alleen maar vervelend en alleen een oplossing voor non-profs

Door AHBdV, dinsdag 8 maart 2011 17:56

Er schijnen ook mensen op de wereld te zijn die Linux op de desktop gebruiken. En daarbij is het niet zo handig als de usb/cd/dvd e.d. niet meer bruikbaar zijn.

Door ameesters, dinsdag 8 maart 2011 21:01

hahaha en dan een grapjas met een pen of een ander dun voorwerp even je reset/uit knop 20 seconde ingedrukt houden door de rack deur heen, of even kortsluiting maken!

Maarje, ze konden in ieder geval niet in je usb/cd, waarbij je je usb toch niet laat automounten en je cd/dvd achter je frontje zit opgesloten, en alleen met een sleutel op krijgt...

Door mrlammers, dinsdag 8 maart 2011 15:42

Okee. Oud nieuws, want dit gat was in februari al dicht.

Voor alle bug-lievende mensen out there: niet iedere bug is een bug. Soms is het een eigenschap van de interface. Gedrag van code, een lengte van een string, etc. Soms leiden eigenschappen onbedoeld tot onverwachte resultaten, of geheugenfouten, wat dan weer een beveiligings issue kán worden - maar niet altijd ís.

Want meestal (in dit geval niet dus) is het dus de eigenschap van de interface: bedoeld gedrag. Dan bedoel ik de auto-run functionaliteit, automatisch mounten van volumes, een progje dat automatisch start en je desktop omgeving die jou als gebruiker niet om toestemming vraagt om iets uit te voeren; Bij gebrek hieraan kun je soms bijvoorbeeld achter de screensaver langs het wachtwoord op de screensaver hacken met behulp van een shellscript. Ik roep zo maar eens wat.
Daar komt nog bij dat dit alleen werkt als je zelf fysiek bij het appraat aanwezig bent. Inbreken op afstand is er dus niet bij. Het eerste security issue is dan altijd nog: een goed slot op je deur.

Naast dat er op de meeste Linux machines allerlei veiligheidsmaatregelen ingebouwd zijn (ASLR, PIE) en er op de machine waarschijnlijk ook wel AppArmor o.i.d. geïnstalleerd is, kan ik met aan zekerheid grenzende waarschijnlijkheid zeggen dat deze 'gevaarlijke bug' 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 (nog) geen rootrechten. Daarvoor moet je je ook weer in allerlei bochten wringen... dus dan moet je nog wat hacken.

Geloof mij nou maar als ik zeg dat de exploit van deze bug geen garanties biedt. Op veel linux machines hebben auto-parsers weinig kans en niet elk script laat zich pushen.
Er zijn dus een hoop aannames en randvoorwaarden waaraan voldaan moet worden voordat een 'hack' via USB werkt.

Het is veel makkelijker om FireWire te gebruiken als je dan toch direct toegang wilt krijgen tot een machine. FireWire heeft DMA en als je een andere computer verbindt, dan kun je er vrij makkelijk in...

Door .oisyn, dinsdag 8 maart 2011 16:51

Voor alle bug-lievende mensen out there: niet iedere bug is een bug.

Klopt. Geldt vooral voor Zend, daar is het nooit een bug, want het is immers gewoon hoe zij het hebben ingetypt, en wat ze intypen definieert het gedrag ipv andersom. Tja, dan heb je idd nooit bugs.

Maar dat is hoe prutsers te werk gaan. Dit is gewoon een bug. In kernel-mode kun je je geen fouten als buffer overflows permitteren, en moet je code gewoon robuust zijn. Dat is (was) deze code niet. Een oversight en niet expres, dat snap ik ook wel, maar weldegelijk een bug die gefixed dient te worden (en dat inmiddels al is).

[Reactie gewijzigd door .oisyn op dinsdag 8 maart 2011 17:34]

Door alex3305, dinsdag 8 maart 2011 15:44

Wat mij telkens weer verbaasd in de grotere softwareprojecten (tevens ook vaak open source projecten) is dat de programmeurs ontzettend veel kennis en ervaring hebben en ontzettend mooie oplossingen kunnen creëren, maar dat dan simpele zaken, zoals het controleren van de lengte van een string vergeten wordt.

Nu is er natuurlijk ook iets voor te zeggen dat zulke overflows moeilijker te vinden zijn bij gesloten systemen dan bij open systemen, zoals Linux, maar het verbaasd mij toch wel!

Door postbus51, dinsdag 8 maart 2011 17:03

Mag het een device driver zijn door een bedrijf in de kernel driver tree geplaatst opverzoek van dat zelfde bedrijf

Door kidde, dinsdag 8 maart 2011 21:16

En wederom werpt de pro-actieve code-auditing van OpenBSD haar vruchten af, lijkt me.

"We plan to replace occurrences of strncpy() and strncat() with strlcpy() and strlcat() in OpenBSD where it is sensible to do so." aldus Theo de Raadt. Erg jammer dat de Linux-code kennelijk niet op dezelfde manier ge-audit wordt, maar gezien de grotere omvang misschien ook wel logisch.

Door MSalters, woensdag 9 maart 2011 00:21

Niet dat die wijziging hier on-topic is. Als Linux een strncpy(dest,src, sizeof(dest)); had gebruikt, dan was er hier ook geen buffer overflow geweest. Dan waren er maximaal 80 bytes naar de bufefr gekopieerd. Het probleem is dat strcpy(dets,src) op geen enkele manier de lengte van dest checkt.

De enige "winst" van strlcpy is dat je daarna veilig een strcpy kunt doen. Maar als je codebase zo goed is dat je toch al overals strncpy gebruikte, dan heb je dus geen winst om strncpy te vervangen door strlcpy.

Door psyBSD, woensdag 9 maart 2011 08:14

grapjas... sizeof(dest) geeft netjes de grootte van de pointer terug. dus 1, 2, 4 of 8, afhankelijk van de architectuur (8bit, 16bit, 32bit of 64bit) van het systeem. - dat werkt dus niet.

[Reactie gewijzigd door psyBSD op woensdag 9 maart 2011 08:14]

Door no-sense, woensdag 9 maart 2011 08:39

Niet als dest een array is. Dan geeft-ie netjes de size in bytes van de array terug.

Door clueless12, dinsdag 8 maart 2011 15:54

Net even een 'grep -r "strcpy(" *' op de hele linux source gedaan en het wemelt er nog van. Ook nog op een aantal plekken waar de source niet gegarandeerd kort is. Wel is het zo dat het daar meestal om namen van hardware in de computer gaat. Is toch wat lastiger een buffer overflow voor te maken dan een USB device.

De linux kernel wordt niet alleen op PC's gedraaid maar ook op router en telefoons (Android). Ik weet niet of die dermate aangepast zijn dat dit niet geldt maar dit kan natuurlijk erg handig zijn om een 'geleende' telefoon even van wat 'monitoring' programma's te voorzien. Of bij een router om toegang te krijgen tot opties die normaal achter een wachtwoord zitten.

Door Dreamvoid, dinsdag 8 maart 2011 16:35

Hoe denk je dat mensen die Android telefoons kunnen rooten? Juist ja: overflow exploits. Idem met iOS jailbreaks, WP7, etc.

Door clueless12, dinsdag 8 maart 2011 16:39

Waarschijnlijk wel ja maar dan moest je altijd nog wel toegangsrechten hebben. Nu misschien door het insteken van een USB device waardoor je even snel iemands telefoon kunt 'tweaken' zonder daadwerkelijk in te kunnen loggen op de telefoon.

Door johnkeates, dinsdag 8 maart 2011 17:13

Dat zegt niets. Je moet eerst diezelfde usb driver hebben, plus een USB poort. Daar naast is een strcpy niet automatisch onveilig, je kan buffer overflows op meerdere manieren afvangen.

Door server4u, dinsdag 8 maart 2011 16:31

Usb verijst nog direct acces...

Oftewel Ik voel me er niet minder veilig op

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

14:54	Adobe-tool converteert Flash-bestand in dhtml
14:06	Deus Ex: Human Revolution verschijnt op 26 augustus

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

13:01 Nieuws

22:34 Productreviews

22:54 Vraag & Aanbod

25-05 Jobs

20:30 Etc.

22:55 Reacties

22:57 Forum

25-05 Gesponsorde acties

00:16 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines