Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 73 reacties

In het opensource-besturingssysteem OpenBSD is een bug ontdekt die al tien jaar in de code aanwezig zou zijn. Aanvallers zouden de weeffout kunnen benutten om ddos-aanvallen op servers uit te voeren.

OpenBSDDe bug is ontdekt in het polling subsystem van OpenBSD, schrijft Phoronix. Door de bug kan een aanvaller met gemanipuleerde file descriptors ddos-aanvallen uitvoeren op servers. De ontdekkers omschrijven de bug als 'kritiek', maar de fout zou desondanks al sinds februari 2004 in de broncode van OpenBSD aanwezig zijn. In Linux zou de fout niet aanwezig zijn. Inmiddels wordt er gewerkt aan een bugfix.

Het is opvallend dat een als kritiek omschreven bug zo lang onopgemerkt in de broncode van OpenBSD heeft kunnen zitten; het besturingssysteem wordt door de ontwikkelaars geafficheerd als een zeer veilig OS door veel aandacht te besteden aan correct geschreven code en de veiligheidsmechanismes in het besturingssysteem.

Moderatie-faq Wijzig weergave

Reacties (73)

De bestempeling als kritiek is gedaan door degene die het gemeld heeft aan Phoronix, niet door ontwikkelaars van OpenBSD. Desalniettemin lijkt het inderdaad op een vrij serieuze bug. Doordat de mailing list thread hierover (http://marc.info/?l=openb...ech&m=141259739204618&w=2) maar paar replies heeft, is het nog even afwachten, al is er al wel een patch voor klaar.

edit: Zoals iemand elders uitwees zou het trouwens gaan om DoS, niet DDoS....

[Reactie gewijzigd door afraca op 7 oktober 2014 09:27]

Phoronix en bij uitbreiding Tweakers hebben weer eens van een muis een olifant gemaakt.

Het gaat over een FIFO/pipe in combinatie met de select() system call.

1) dit is per definitie een lokaal concept, dus zoals anderen aanhalen: maak van die DDoS maar een DoS. Een FIFO/pipe kun je niet remote behandelen.
2) Het grootste gebruik van pipe's is bij command-line utilities (bvb: grep "..." file | gzip > output.txt)
en daar speelt dit probleem niet omdat die geen select() gebruiken (anders was dit probleem ook veel vroeger gevonden)
3) Veel andere tools zullen ook de combinatie met select() niet maken. Anders was deze bug al langer aan het licht gekomen (al was het maar door detectie van een file descriptor leak).

En wat de mogelijkheden tot exploit betreft: er zijn (althans in Linux) slechts 2 manieren om een file descriptor door te geven:
1) via exec() (i.e. een nieuw process starten). Maar dan kon je even goed rechtstreeks het process opstarten om je DoS uit te voeren, zonder die round-trip met een FIFO.
2) via een unix socket. Deze kan tussen users met verschillende rechten gebeuren dus lijkt me de belangrijkste attack vector. Alleen zijn de tools die dit doen nogal dungezaaid...

Ik wil de CVSS score nog wel afwachten, maar ik vermoed dat deze niet zo hoog zal zijn.
Wat echter wel vaak gebeurt is dat een select() call wordt gedaan op een FIFO/pipe, waarbij die laatste dan wordt gebruikt om naar de select()-ende thread to communiceren vanuit een andere thread.
Op hun website staat:

Only two remote holes in the default install, in a heck of a long time!

Ben benieuwd of ze dit nu aanpassen naar 3 ;)
Het is geen remote hole, want het gaat om een DoS aanval, niet een DDoS aanval zoals in het bericht incorrect vermeld staat.
Het is geen remote hole want de bug verleent je geen toegang tot het systeem... het maakt alleen een (D)DOS (1 vd 2 maakt niet uit welke) aanval makkelijker.
Aangezien de bug met een gemanipuleerde file descripter getriggerd wordt, moet er lokale code gedraaid worden.
Op de meeste systemen kan je op de een of andere manier wel lokaal DOS'en. Release critical misschien, en dan alleen omdat OpenBSD anaal is. Beetje bs om te doen alsof dit veel voorstelt.
Ik vind het niet heel opvallend eerlijk gezegd. De codebase is super groot en 10 jaar geleden waren er nog niet zulke goede code reviews zoals nu het geval is.

Daarnaast klopt het niet dat je een DDoS hiermee kunt uitvoeren. Een betere term is DoS (Denial Of Service). Distributed DoS is helemaal niet nodig en kun je hiermee ook niet gebruiken. Met deze bug kun je een lokale service manipuleren zodat het zijn werk niet meer kan doen en dat is dus geen DDoS maar een gewone DoS.

[Reactie gewijzigd door Rutix op 7 oktober 2014 09:34]

10 jaar geleden waren er nog niet zulke goede code reviews zoals nu het geval is.
Dit argument snap ik niet helemaal. Bedoel je nu dat code die 10 jaar geleden gereviewd is, nooit meer opnieuw gereviewd hoeft te worden?
Dat zou je juist moeten omkeren: als we nu beter kunnen reviewen dan 10 jaar geleden, dan moeten we dus eerder gereviewde code ook opnieuw bekijken.
Sowieso is code review een ongoing process: de code is continu in ontwikkeling, dus moet er steeds opnieuw gekeken worden of iets nog veilig is. Het is vaak zo dat juist bepaalde combinaties van software tot een lek leiden. Code in software X was mischien ooit veilig, totdat er in software Y een nieuwe feature is toegevoegd die software X ook beinvloedt.
Dus de context waarbinnen software X gebruikt wordt, verandert dan, en dus moet er opnieuw gekeken worden of software X ook binnen die context wel veilig is.
Dat is helemaal waar in de ideale situatie. Maar bij een grote codebase dan kun je nooit 100% elk stukje code elke keer reviewen. Als je kijkt hoe klein de fix is voor deze bug dan is het niet heel opvallend dat zoiets over het hoofd word gezien. Het zijn nog altijd mensen die reviewen en ernaar kijken. Het kan best zijn dat er nooit meer iets is geweest dat de scope van deze code heeft geraakt en dus niet meer gereviewed is.
Maar bij een grote codebase dan kun je nooit 100% elk stukje code elke keer reviewen.
Dat zeg ik niet, maar in 10 jaar tijd mag ieder stukje code toch hopelijk meer dan 1 keer gereviewd zijn.
Het kan best zijn dat er nooit meer iets is geweest dat de scope van deze code heeft geraakt en dus niet meer gereviewed is.
Dit is dus een foute insteek: je moet code niet alleen reviewen op basis van 'scope raken' (sowieso kun je daar al de fout maken dat iets wel een bepaalde scope raakt, maar dat je dat over het hoofd ziet).
Je moet code reviewen omdat mensen nu eenmaal fouten maken. En ook bij reviews worden fouten gemaakt, dus dezelfde code meerdere keren reviewen is noodzakelijk.
Working code is not bugfree code.

[Reactie gewijzigd door Scalibq op 7 oktober 2014 13:54]

Zoals ik al zei is de situatie die jij voorschets de ideale situatie. In de praktijk is dat heel anders en zie je vaak dat er door tijdgebrek niet alles meerdere keren word gereviewed. Dus helemaal waar dat het een foute insteek is maar mijn eerste opmerking van dat ik het niet opvallend vond is nog steeds valide omdat het in de praktijk anders aan toe gaat ;)
Bij iedere gevonden bug kun je de garantie afgeven dat dit niet de laatste bug was. Dat geldt voor closed en voor open source. En voor security en non-security gerelateerde bugs. Overigens stond in mijn HTS tijd al in een aantal diktaten voorin een disclaimer dat er gegarandeerd fouten in stonden. En bij het vinden van een fout de voorgaande stelling nog steeds waar was.

Voor de personen die denken: waarom worden die fouten nu allemaal gemaakt? Dan is er een simpel antwoord: omdat we mensen zijn en fouten maken. Zolang een manager geen foutloze brief kan schrijven, zullen zijn developers die een veelvoud aan (regels) code schrijven ook fouten maken. Een compiler of interpreter controleert wel de syntax. En een taal kan je wel beschermen voor fouten (bijv. garbage collection), maar niet voor structurele fouten, buffer under of overflows, en wat er allemaal meer mis kan gaan. De ene taal is daar wel beter in dan de andere, maar kernels, drivers etc is vaak nog C/C++. En die talen bieden veel flexibiliteit, en veel ruimte voor fouten.

Ik vermoed dat het aantal hackers dat in staat is om miljoenen regels code te doorgronden vrij klein is, maar dat ze die kennis wel delen met personen die 'selchts' misbruik weten te maken van dit soort lekken (of zelfs de tools daarvoor krijgen). Dat is inderdaad crimineel, maar net zoals politie keurmerk veilig wonen: je bant er het inbrekersgilde niet mee uit de wereld. Het enige verschil is dat diefstal van digitale gegevens ongemerkt kan gebeuren (en daarom staat het ook niet in de krant).

Ik ben zelf software ontwikkelaar en zowel de heartbleed als shell shock bug zijn me bekend. Door gebrek aan tijd en mankracht is het gewoon onmogelijk om binnen een redelijke tijd (zeg 3 maanden) alles te adresseren. Ik vind het knap als bedrijven binnen 1-2 weken fixes hebben. Maar dan krijg je de admins die de patches moeten uitrollen. Zoiets duurt veel langer. Als je op iedere security bug moet reageren met een fix, dan houd je niet veel tijd meer over voor overige zaken.

Net zoals je bijv. je loonstroken op een veilige plek (maar doorgaans niet in een kluis) thuis bewaart, moet je (kritische) bedrijfsapplicaties achter voldoende 'voordeuren' afschermen. Dus, naast het fixen van security lekken, is ook de admin verantwoordelijk voor het afschermen van de applicatie van de buitenwereld. Internet is inherent onveilig. De kwaliteit van sluit- en hangwerk van je huis is een afspiegeling van de waarde in huis zeg maar (en als er niets te halen is, laat je de voordeur openstaan :-)).
Ik snap niet helemaal waarom dit nieuwswaardig is? Zo kun je elke security advisory van OpenSSL ook wel gaan behandelen als nieuws...
We hebben het hier niet over een typo bug he. Het gaat hier om een filedescriptor welke een niet-POSIX gedrag vertoond.. Het probleem is dat volgens de POSIX specs de descriptor een EOF moet terug geven, maar de descriptor veranderd hier in een write state en daardoor kun je hem niet meer uitlezen en dus blijft een select (zelf bij een non-blocking call) hangen.

Deze bug zit in het POSIX subsysteem van BSD en daardoor zijn vrijwel alle deamon processen op de betreffende server dus vatbaar voor deze bug. Voor alsnog is er geen melding gemaakt van een network facing deamon welke vatbaar is voor deze bug. Echter als deze wordt gevonden voordat men de fix heeft doorgevoerd, dan kun je wel degelijk spreken over een potentiele DDOS exploit..

Juist door de heartbleed en shellshock bugs worden veel core systemen onder de loep genomen. Overigens is OSX ook gebaseerd op een BSD variant en ook daar is dus de bug zeer waarschijnlijk aanwezig..

Iedere IT-er moet de afgelopen weken van shellshock hebben gehoort. Toch kwam gisteren een artikel voorbij dat onder andere Yahoo en Winzip hun systemen niet van de patch(es) hadden voorzien.

Een nog veel groter probleem is dat als een bedrijf dan wordt gehacked dat ze gaan roepen dat het een oud systeem betrof welke eigenlijk door niemand wordt gebruikt.Maar wat velen dat vergeten is dat men wel toegang tot dat oude systeem heeft gehad en dat oude systeem heeft vrijwel altijd toegang tot een intern netwerk.Veel bedrijven hebben geen interne firewall en via zo'n oude machine zijn dan ineens ook al je gloednieuwe servers varbaar voor tal van bugs en exploits welke normaal via firewalls worden geblokkeerd. Op veel servers zijn leesbare credentials aanwezig om bijvoorbeeld toegang tot databases te krijgen. Via Yahoo's eigen zoekmachine is hier niet zo lastig om Yahoo mailadressen te achterhalen en vervolgens proberen toegang tot die mailboxen te krijgen.

Bugs zoals heartbleed en shellshock behoren wat mij betreft op de voorpagina van de landelijke dagbladen te staan. Waarom publiceerd het Nationaal Cyber Security Centrum eigenlijk nooit waarschuwingen? Ze hebben zelfs nog nieteens een publicatie gemaakt over shellshock. Toch wel een alarm code rood!

Daarbij als je dagelijks in de krant zou lezen hoeveel websites er worden gehacked door een van de top 10 OWASP methodes, zou ook de algemene burger veel beter beseffen hoe onveilig het internet feitelijk is. De kans dat jij op straat wordt aangevallen en een trap tegen je hoofd krijgt is vele malen kleiner dan dat je gegevens op straat komen te liggen door een SQL-injection. Toch lees ik elke week in de krant over uitgaansgeweld, maar vrijwel nooit over lekke websites in de krant.. Misschien heeft Opstelten dan toch gelijk dat wij privacy helemaal niet zo belangrijk is. Want belangrijke zaken staan in de krant, toch?!
Oh ik ben het helemaal mee eens dat dit een kritieke bug betreft en dat je bedrijven die zich niet actief beschermen door security patches zsm door te voeren op hun systemen best incompetent zou kunnen noemen. Ik vraag me wel af hoeveel nut het heeft om mensen die er geen verstand van hebben deze informatie te geven, behalve als elke berichtgeving gealgemeniseerd word naar "systeem x is lek", wat niet echt nuttig is imo. Ik denk dat het zijn doel dan een beetje voorbij schiet.

Het punt van mijn comment was de vraag waarom nou net deze bug weer ophef genereert, terwijl er na de heartbleed bug al weer een aantal OpenSSL security advisories zijn geweest (o.a. eentje waar met een MITMA onveilige encryptie geforceerd kon worden op een verbinding), en op bijvoorbeeld de debian security advisory mailing list dagelijks updates langs komen die security fixes krijgen.
Deze bug zit in het POSIX subsysteem van BSD en daardoor zijn vrijwel alle deamon processen op de betreffende server dus vatbaar voor deze bug. Voor alsnog is er geen melding gemaakt van een network facing deamon welke vatbaar is voor deze bug. Echter als deze wordt gevonden voordat men de fix heeft doorgevoerd, dan kun je wel degelijk spreken over een potentiele DDOS exploit..
Correctie. Enkel de daemons die FIFO's krijgen van andere processen of ze zelf uitdelen.

En dan nog heb je enkel een file descriptor leak. Ultimately kan je dan wel gaan tot aan de maximum FD limiet (en heb je dus je DoS), maar welke daemons krijgen of delen FIFO file descriptors uit?

[Reactie gewijzigd door H!GHGuY op 7 oktober 2014 13:02]

OSX had Freebsd als basis niet Openbsd en in Freebsd kwam dit (nog) niet naar boven afaik
Toch lees ik elke week in de krant over uitgaansgeweld, maar vrijwel nooit over lekke websites in de krant.. Misschien heeft Opstelten dan toch gelijk dat wij privacy helemaal niet zo belangrijk is. Want belangrijke zaken staan in de krant, toch?!
Ehh ja maar is een klap tegen je hoofd niet vele malen erger dan dat je NAW gegevens op straat komen te liggen?
Lekker weer in werktijd van je nieuwe werkgever op Tweakers onzin typen ten koste vam produktie en voortgang van het bedrijf.

Weet je baas hiervan ? Ik denk het niet maar misschien nu wel.

Je blijft maar volharden met wangedrag onder werktijd. Dat heet hardleers en je dupeert daarmee bedrijven.
Tijd en reputatie van OpenBSD
Er is nog geen fix/patch beschikbaar zo te lezen?

Lekker handig om dit nieuws dan wereldkundig te maken...
Het is goed dat er de laatste tijd veel fouten worden opgespoord in open source software en naar buiten worden gebracht. Dit komt ten goede vna de code. Beter dan closed source waar veel fouten alleen 'formeel' in een notitie naar buiten worden gebracht en de patching ervan soms gewoon via een stille patch wordt gedaan imo.

Since de heartbleed bug is men toch wat harder gaan zoeken, top. Vooruitgang enzo. :)

@HooksForFeet; Ik ben nooit uitgegaan van het principe "Open source is veilig want er kijken veel mensen mee" Het wordt veiliger omdat er meer mensen mee kijken. Uitgaan dat software (open of closed) veilig is puur door een manier van development en coding is gewoon naief.
Ik vraag mij dan ook af of je statement eigenlijk vanaf moment 1 wel klopt op dat moment. Maar dat is meer een persoonlijke vraagkwestie.

[Reactie gewijzigd door Auredium op 7 oktober 2014 09:39]

Zo lang niemand (echt niemand) op de hoogte is van zo'n te misbruiken bug is er natuurlijk niets aan de hand. Het wordt pas een probleem als personen met verkeerde bedoelingen erachter komen voordat de makers/onderhouders van de code het weten...
Zo lang niemand (echt niemand) op de hoogte is van zo'n te misbruiken bug is er natuurlijk niets aan de hand. Het wordt pas een probleem als personen met verkeerde bedoelingen erachter komen voordat de makers/onderhouders van de code het weten...
Je snapt dat je daarmee het beste argument *tegen* open source geeft hŤ
Geldt net zo goed voor closed-source.
Wie zegt dan dat dat niet gebeurd is? Als de bug er al 10 jaar zit dan is er een redelijke kans dat criminelen of de NSA 'm al eerder gevonden hebben en 'm misbruiken...
Het gaat om een ddos aanval, dat lijkt me niet super interessant voor de NSA.

Volgens Wikipedia is de het doel van de NSA:
-Informatie verwerven en analyseren
-Beschermen tegen cyberaanvallen.

Een DDOS-aanval levert geen nieuwe informatie op, en beschermt geen Amerikaanse computer-netwerken. Het is een aanvals-wapen, en hoort zodoende meer thuis bij het leger.
Ddos is wel ingeressant voor de NSA. Zo kan een control server van een botnet even worden verlamd, of een machine die een ddos aanval uitvoert door dese daarmee aan te vallen.

Ook kan de aandacht worden afgeleid door server 1 aan te vallen en de daarbij horende server 2 te hacken.
De NSA gebruikt zelf ook botnetten en inderdaad ook cyberaanvallen.

NSA Has A 50,000 Computer Botnet From Secretly Installing Malware Around The Globe

NSA May Have Used IRC Botnets to Exploit Heartbleed for Last Two Years

[Reactie gewijzigd door fevenhuis op 7 oktober 2014 18:25]

Als je een systeem kan platleggen middels een DDOS waardoor e.e.a. gereboot, kan je in sommige gevallen binnenkomen tijdens het boot-proces.

Dus zeker weten wel interessant :)
Zo leuk dat de NSA overal wordt bijgehaald...

Aluhoedjes!!!!!!
Maakt het niet minder waar dat criminele organisaties zoals Vupen voor heel grof geld dit type bugs verkoopt aan precies dat soort organisaties.
Ze leven ervan, je kan er echt gevoeglijk vanuit gaan dat een kwetsbaarheid zoals deze die 10 jaar bestaan heeft door dat soort clubs al lang en breed is gevonden.

En natuurlijk wordt de NSA genoemd, die is het meest bekend.
Maar de BVD en AIVD en zo nog een hele reeks aan afkortingen zijn op dat vlak net zo erg en net zo hard bezig als die club.

Om dan meteen aluhoedjes te roepen is aanzetten tot struisvogel politiek.
Je hebt zo te zien wel lokaal access nodig om dit te kunnen uitbuiten. En dan heb je toch al een probleem. Heel misschien is er software die van buitenaf kan worden getriggerd om FIFO's te schrijven, maar ik zou niet zo weten wat zou moeten zijn. In dat geval is het misschien wel van buitenaf uit te buiten. Wanneer het echter wel zeker een probleem is, is wanneer je restricted gebruikers op je systeem laat inloggen. Deze kunnen het dan lam leggen.
jammer dat die personen met verkeerde bedoelingen nooit vertellen hoe en waar die lek zit die zij gebruiken
Het is goed dat er de laatste tijd veel fouten worden opgespoord in open source software en naar buiten worden gebracht. Dit komt ten goede vna de code. Beter dan closed source waar veel fouten alleen 'formeel' in een notitie naar buiten worden gebracht en de patching ervan soms gewoon via een stille patch wordt gedaan imo.
Waarom? Die stille patch komt de closed source code dan toch net zo goed ten goede?

Interessant overigens hoe "bij open source weten we het tenminste" sinds kort het standaardargument is geworden nadat het "Open source is veilig want er kijken veel mensen mee" argument zo ongenadig onderuit is gegaan.

[Reactie gewijzigd door HooksForFeet op 7 oktober 2014 09:29]

Interessant overigens hoe "bij open source weten we het tenminste" sinds kort het standaardargument is geworden nadat het "Open source is veilig want er kijken veel mensen mee" argument zo ongenadig onderuit is gegaan.
Het belangrijkste argument voor de veiligheid van open source is dat je problemen zelf kan (laten) oplossen. Alle software bevat fouten. Belangrijker dan het aantal fouten is hoe die fouten worden opgelost. Bij closed source ben je afhankelijk van de leverancier. Als die het probleem niet kan of niet wil oplossen dan heb je pech.
Nee hoor, ondanks dat Firefox geen enkele moderne security feature ondersteund zoals bijvoorbeeld ASLR kan ik het forceren dat Firefox wel ASLR gebruikt :)
Zonder de source aan te passen.

Of de hele meuk sandboxen met sandboxie.

Voor veiligheid van je systeem zou je niet afhankelijk moeten zijn van de software en hun makers. Of dit nou open of closed is, maakt geen ruk uit. Je bent niet alleen van de leverancier afhankelijk.
Nee hoor, ondanks dat Firefox geen enkele moderne security feature ondersteund zoals bijvoorbeeld ASLR kan ik het forceren dat Firefox wel ASLR gebruikt :)
Zonder de source aan te passen.
Tja, ASLR helpt tegen een bepaald soort fouten. Het is geen toverstokje waardoor alles opeens veilig is. Tegen Heartbleed of Shellshock helpt het bijvoorbeeld niet.
Voor veiligheid van je systeem zou je niet afhankelijk moeten zijn van de software en hun makers. Of dit nou open of closed is, maakt geen ruk uit. Je bent niet alleen van de leverancier afhankelijk.
Dat er soms andere oplossingen mogelijk zijn neemt niet weg dat het probleem bij de wortel aanpakken nodig blijft.

Mijn punt is dat je bij open source je problemen in principe zelf kan oplossen, onafhankelijk van de leverancier. Als je fiets een lekke band heeft kun je dat ook oplossen door de bus te nemen maar dat heeft ook nadelen. Als de bus nemen alleen maar voordelen had dan was je nooit gaan fietsen. Je wil dus je band (laten) plakken. In de softwarewereld gaat dat het beste als je de source hebt.

[Reactie gewijzigd door CAPSLOCK2000 op 7 oktober 2014 16:31]

Miljoenen lijnen aan code, die met allerlei context te maken hebben plus een slim persoon die het om zeep weet te brengen/toe weet te passen als exploit.

Het is en blijft mensenwerk.
Het gaat er niet om dat het mensenwerk is, maar al jarenlang horen we bij open source vooral dat het zo veilig is want iedereen kijkt mee, en bugs worden daardoor sneller gevonden. Maar het blijkt de laatste tijd toch niet helemaal zo te zijn... Dat dat logisch is, is een ander verhaal.. je leest niet voor je lol even op zaterdagmiddag de complete source van een os door als ontspanning, maar dat hoefde je 5 jaar terug niet te zeggen want dan snapte je er geen reet van en was je vooral "anti open source". Maar natuurlijk, het wordt geschreven door mensen, de review gebeurt door mensen, dus een fout kan er gewoon inzitten. Accepteer dat, en kap met roepen dat open source veilig is omdat iedereen de code kan inzien. Dat je iets kunt, wil niet zeggen dat het gebeurt. (feit is wel dat in theorie een bug eerder gevonden kan worden als de source open is, en je kunt eventueel de bug zelf fixen in plaats van te moeten wachten op de leverancier tot die met een patch komt).
... en je kunt eventueel de bug zelf fixen in plaats van te moeten wachten op de leverancier tot die met een patch komt).
Ja, maar dat zal zelden gebeuren. Want je introduceert dan in principe een fork, waardoor je keuzemogelijkheden afsluit. Daarin wil je ook niet over ťťn nacht ijs gaan
Tien jaar oude bug ontdekt in OpenBSD
en
In Linux zou de fout niet aanwezig zijn.
Wat een rare opmerking. Wat heeft Linux met OpenBSD te maken?
Wat een rare opmerking. Wat heeft Linux met OpenBSD te maken?
Zo raar vind ik het niet. Hoewel linux en OpenBSD op zichzelf staande projecten zijn, wordt er wel bepaalde code gedeeld (denk bv aan OpenSSL, de GNU compiler, Xorg, Gnome/KDE/etc). Zo zou het dus best kunnen dat deze bug ook in linux distributies is terechtgekomen. Bij OpenSSL was dit namelijk ook het geval.
Daarnaast is bash ook wel een goed voorbeeld: OS X heeft ook niets met linux te maken, maar gebruikt wel standaard de bash shell.
Mensen die op OpenBSD zelf de bash-shell hadden geinstalleerd, waren ook kwetsbaar.

Dus ja, ik vind het wel goed dat ze dat voor de zekerheid erbij vermelden.
[...]


Zo raar vind ik het niet. Hoewel linux en OpenBSD op zichzelf staande projecten zijn, wordt er wel bepaalde code gedeeld (denk bv aan OpenSSL, de GNU compiler, Xorg, Gnome/KDE/etc). Zo zou het dus best kunnen dat deze bug ook in linux distributies is terechtgekomen. Bij OpenSSL was dit namelijk ook het geval.
Daarnaast is bash ook wel een goed voorbeeld: OS X heeft ook niets met linux te maken, maar gebruikt wel standaard de bash shell.
Mensen die op OpenBSD zelf de bash-shell hadden geinstalleerd, waren ook kwetsbaar.

Dus ja, ik vind het wel goed dat ze dat voor de zekerheid erbij vermelden.
Dit betreft Kernel code geen add-on code.
Dit betreft Kernel code geen add-on code.
Mensen met wat minder verstand van zaken weten niet direct wat dat betekent (en sowieso, zelfs in twee verschillende kernels zou dezelfde fout voor kunnen komen). Ik vind het dus duidelijker om expliciet te vermelden dat linux niet getroffen is.
OpenSSL is een library, en die draaien boven op het os, en wordt door meerdere OS'en gebruikt. DIt is een bug in het OS zelf, in de kernel, die code is tussen Linux en de BSD familie niet gedeeld.

Een interessantere vraag is of deze bug zich ook binnen andere OS'en uit de BSD familie bevind. Besturingssystemen zoals FreeBSD en NetBSD, zijn uiteindelijk forks van dezelfde codebase, en zullen ook recentere wijzigingen van elkaar overnemen. Daarom zou een opmerking over de aanwezigheid van de bug in andere BSD families wel zinvol lijken, maar Linux, dat is een totaal ander project.
Wat een rare opmerking. Wat heeft Linux met OpenBSD te maken?
dit dus. Ik begreep het zelf ook niet.

[Reactie gewijzigd door Marlinc op 7 oktober 2014 10:23]

Het is beide Unix..
linux!=unix
Het is beide Unix..
Linux is geen Unix c.q. geen Unix evolutie. Er zijn "alleen" goede ideeŽn van Unix geleend.

Zie ook Functional UNIX in deze link.
In ander nieuws, In Windows zou de fout niet aanwezig zijn.
Zou een groot IT bedrijf dat veel verdiend/kan dankzij open-source soms personeel moeten laten kijken / zoeken naar bugs in Linux ? Al doen bedrijven als IBM , Intel , etc dat wel beetje zie ik soms.
Helaas gebruiken die grote bedrijven bepaalde zaken ( zoals getroffen door de heartbleed bug) massaal zonder daarvoor enige verantwoordelijkheid te nemen. Ze blijken zelfs de code niet gecontroleerd te hebben. Mogelijk dat al deze stappen toch op bepaalde bewuste keuzes wijzen waarbij Snowden al snel in herinnering komt.
Als maar genoeg mensen denken "de anderen controleren wel de code die we gebruiken", controleert niemand meer de code.. Dat is meestal het geval!
Een fenomeen dat helaas bestaat. Degenen die het wel doen, investeren meteen in eigen kennis. Dat is wel een goede strategie vind ik. Ik hoop dat zoiets op langere termijn ook altijd beloond wordt met goede prestaties van het gehele bedrijf.
Tja helaas wordt het ook veel als verspilling van tijd gezien. "Het werkt toch? Lekker laten en aan <feature> werken" is een niet ongewone reactie van je chef. Als code eenmaal gecontroleerd is, ergens in het jaar kruik, dan zou het moeten blijven werken, en hooguit worden er bugs geplet, maar security? Daar is het lastig om testcases op te zetten (de goeie gaatjes zijn uniek), en het is een ongelofelijk tijdrovend klusje dat veel kennis vereist. Tijd = geld.

OpenSource heeft nogal eens mensen die gewoon uit nieuwsgierigheid een stuk code aan stukken trekken, en dan heb je een kans (geen garantie!) dat zoiets boven water komt.
Misschien zagen ze dit toch niet als een echt beveiligingslek. Je komt er het systeem in ieder geval niet mee binnen.
Bugs? What bugs? They are features!
Een DDOS aanval? Als ik dit zo lees geldt deze fout voor lokaal draaiende processen. Hoe zou je die van buitenaf moeten exploiten?

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True