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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 48, views: 21.893 •

BIND-versies 9.7, 9.8 en 9.9 voor het Unix-platform, software die gebruikt wordt door dns-servers, blijken een ernstige kwetsbaarheid te bevatten. Hierdoor kunnen aanvallers niet alleen dns-servers offline halen maar ook andere applicaties op de server benaderen.

De kwetsbaarheid in BIND 9.7, 9.8 en 9.9 is volgens Threatpost aanwezig op de Unix-versies van de dns-software; de Windows-versie zou de bug niet bevatten. De kwetsbaarheid is aanwezig in een library-bestand dat tijdens het compileren van BIND wordt gebruikt en wordt ingezet voor het verwerken van reguliere expressies. Een aanvaller kan de kwetsbaarheid benutten om een 'out of memory'-error te genereren op een dns-server, waarna het systeem kwetsbaar wordt en offline zal gaan. Ook zou het mogelijk zijn om andere applicaties op de betreffende server aan te vallen. Details over mogelijke exploitcode zijn niet vrijgegeven, maar deze zou relatief eenvoudig zijn te ontwikkelen.

Omdat de BIND-software op een groot aantal dns-servers wordt toegepast en daarmee een belangrijk onderdeel is van de infrastructuur op internet, is een kwetsbaarheid in deze software potentieel zeer ernstig. Het Internet Systems Consortium, dat die BIND-software beheert, heeft inmiddels via een security advisory er bij systeembeheerders op aangedrongen om BIND zo snel mogelijk te patchen of te upgraden.

Reacties (48)

Als ik het zo lees dit de kwetsbaarheid niet direct in BIND zelf, maar in een onderliggende library waar BIND gebruik van maakt.

Het ISC laat verder weinig los over welke library het is: "A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems"

Met nadruk op "A library", maar welke dan? Zijn hiermee ook niet andere services die gebruik maken van deze library kwetsbaar?

Dat stukje mis ik in het verhaal.
lijkt om libregex te gaan, zie ook hier en hier

[Reactie gewijzigd door jessesteinen op 28 maart 2013 17:46]

Is het hiermee in theorie mogelijk om praktisch het hele internet onderuit te halen (De DNS servers)?

Of gebruiken die root servers een embedded OS?
De meeste grote/belangrijke DNS-servers zijn redundant met twee of meer verschillende softwares. Ik was deze week bij EURid (.eu) en zij gebruiken BIND met Yadifa (hun eigen serversoftware) als backup. Als BIND door een exploit (of ter preventie) neergehaald wordt neemt Yadifa het over (en vice-versa).

Je mag gewoon geen single points of failure hebben, niet in hardware en niet in software.
Hopelijk gebruiken die niet libregex dan :D
Om nog maar te zwijgen over layer7 inspectie/IPS op de firewalls die zo'n kwetsbaarheden ook tegenhoudt.
Ik zal voor de zekerheid best wel ff een mailtje sturen naar onze firewall leverancier of zij deze al hebben opgenomen in hun database :9
Helemaal waar.
Waar ik mij wel over verbaas is dat de programmeurs van BIND niet wat meer bij hun eigen code proberen te houden, al die libraries zijn namelijk niet zo eenvoudig te testen op problemen. Dan moet de wereld er zo achter komen dat opeens een veel gebruikt software pakket niet veilig is met een bepaalde library.
Sowieso, waarom regex? Gewoon overbodig.

http://xkcd.com/1171/
Nee, laat elke programmeur telkens het wiel opnieuw uitvinden. libs bestaan net om veelgebruikte code niet telkens opnieuw te moeten schrijven. En waarom regex? Er zal blijkbaar wel nut voor zijn, anders werd het niet ondersteund door BINND.
Sowieso, waarom regex? Gewoon overbodig.

http://xkcd.com/1171/
Wat zou jij dan gebruiken ipv regex?

Ja als je niet met regex kan werken dan kan het een probleem zijn, inderdaad geeft het voor menigeen prutser problemen. :D
Omdat regexen enorm efficient zijn om user input te controleren misschien? Tuurlijk kan je zelf een algoritme schrijven dat hetzelfde doet, maar dat gaat veel tijd kosten en dikwijls zo lek zijn als een zeef.

De basic libraries op unix zijn best wel stabiel en goed getest, overal kan een bug in gevonden worden. Geloof me: er zijn genoeg mensen die met een kammetje over de code in bvb libxml en libregex gaan om exploits te zoeken.
waarom regex? Gewoon overbodig.

http://xkcd.com/1171/
Wat een onzin. Regexen zijn helemaal niet overbodig. Waar het mis gaat is dat mensen ze gaan gebruiken in gebieden waar ze juist wat minder van toepassing zijn. Zoals met vrijwel alle spreuken op het gebied van software development geldt ook in dit geval dus dat het niet Šltijd opgaat. Weten wanneer iets wel toe te passen ookal wordt het in het generieke geval afgeraden is wat je een goede programmeur maakt. Gewoon maar rŁcksichtslos dingen napraten in ieder geval niet.
Nee hoor:

*.domein.extentie. CNAME xxx.xxx.xxx.xxx

De *.domein.extentie word door BIND afgehandeld met een RegExp
Volgens mij werkt dat zo niet. Ik weet wel dat NAPTR en SRV records regexps kunnen bevatten.
Regexen zijn heel nuttig om efficient string matches mee te schrijven. Dezelfde flexibiliteit haal je echt niet met simpele wildcards of andere oplossingen. Het feit dat je het zo afkraakt is voor mij genoeg reden om te geloven dat jij nog nooit software hebt geprogrammeerd, of als je dat wel doet, het voor geen meter kan. Daarmee wil ik natuurlijk niet beweren dat een goede programmeur per definitie regexen gebruikt, maar vooral dat een goede programmeur de nuttigheid van mogelijkheden goed kan inschatten.

Verder vind ik het juist goed als developers niet overal hun eigen oplossingen voor schrijven en veelgebruikte libraries hergebruiken. Wat geeft jou het idee dat eigen code beter zou zijn? De shared libraries zijn over het algemeen veel beter getest. Nieuwe code bevat altijd bugs. Hoe snel die bugs gevonden worden hangt af van de hoeveelheid dat het gebruikt wordt.

En dan nog iets. Als je libraries gebruikt die andere partijen ook gebruiken, kunnen al die andere partijen ook bugs vinden en patches insturen. Dat heb je met eigen code niet. Alle bugs die je niet zelf vind, vind een cracker wel voor je, en dan is het al te laat.
Gewoon alle belangrijkste IP nummers uit je hoofd leren. Geen man overboord.
Mmm, kan. Wordt alleen lastig met een virtual server :P
Nee hoor, werkt prima:
[code]
freaky@flaptoppy ~ $ telnet `dig +short www.tweakers.net` 80
Trying 213.239.154.20...
Connected to 213.239.154.20.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.tweakers.net
Connection: close

HTTP/1.1 301 Moved Permanently
Server: Apache
X-Tweakers-Server: pontus
Location: http://tweakers.net/
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
X-Pad: avoid browser bug
Transfer-Encoding: chunked
Date: Thu, 28 Mar 2013 21:00:56 GMT
X-Varnish: 1945654920
Age: 0
Via: 1.1 varnish
Connection: close

00128
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
<P>The document has moved <A HREF="http://tweakers.net/">here</A>.
<HR>
<address>Apache Server at www.tweakers.net Port 80</address>
</BODY></HTML>
0

Connection closed by foreign host.
freaky@flaptoppy ~ $ telnet `dig +short www.tweakers.net` 80
Trying 213.239.154.20...
Connected to 213.239.154.20.
Escape character is '^]'.
GET / HTTP/1.1
Host: tweakers.net
Connection: close

HTTP/1.1 200 OK
Server: Apache
X-Tweakers-Server: plutus
Expires: -1
Cache-Control: private, max-age=0
P3P: CP="ALL DSP COR CURa ADMa DEVa HISa OUR STP UNI STA"
... (nee ik ga m'n login cookie hier niet posten ;)
[/code]

Zie?
offtopic:
I moest lachen toen ik je hostname las :)
Zo kan ik het ook. Met dig doe je alsnog een dns lookup, en jouw commando werkt dus echt niet meer als alle dns servers plat liggen.
IPv4 gaat dan nog maar probeer het eens met IPv6...

Daarnaast erg lastig met een webserver die naar de header kijkt en je op basis daarvan de juiste pagina serveert...
Nee joh. Daar heb ik een PC voor. Ik zet het hele internet in /etc/hosts :+
De meeste root servers gebruiken inderdaad BIND, een aantal andere draaien NSD. Ik vermoed dat de DNS operators al op de hoogte zijn gebracht van dit issue.
Overstappen op Windows dns servers dan maar...
Net of die waterdicht zijn...
Prachtig om te zien dat er ook mensen posten die niet weten waar het over gaat.

Gelukkig draait het gros van de low-level netwerkapparatuur op een BSD / Unix variant.
Anders hadden we waarschijnlijk op internet het snelheidsequivalent van 5 jaar geleden gehad.

Daarnaast hadden alle root servers in Amerika down geweest na het grapje van (aanhangers van) Cyberbunker.
@mcetweaker
En dan om de ~128 dagen moeten rebooten omdat je server offline *moet* voor update rondes e.d?

En wat dacht je van virussen, malware.. extra load door de GUI en weet ik veel. Je vergeet even dat de root servers van het internet geen nieuwe machines zijn.
Apart dat Debian een EOL versie 9.7 gebruikt en niet de 9.6 LTS versie, die is tenminste nog tot juni gesupport en niet kwetsbaar.

Zou dnsmasq een goede backup kunnen zijn?

[Reactie gewijzigd door Soldaatje op 28 maart 2013 17:56]

Maar het probleem zit dus al niet in BIND zelf maar wel in een bijkomende library. Bijkomend zorgt Debian bij security issues zelf voor de nodige patches, indien nodig word code van een nieuwere versie gebackport naar de oude versie om deze te patchen. Zolang je Debian distributie ondersteuning krijgt, krijgen alle paketten die ermee werden meegeleverd ondersteuning.
Ik heb anders op het moment van schrijven (2 dagen na het bericht) nog steeds geen update voor bind 9.7 op debian 6.0.7. Niet dat m'n dns server zo belangrijk is, ik gebruik m alleen intern, maar ik had van debian een snellere fix verwacht.
Vind PowerDNS zelf wel fijn. Geen ervaring met root server loads tho' :)
Over het algemeen is Debian 1 van de eerste die security problemen fixed. Zie ook http://www.debian.org/security/ .
Ik beheer/beheerde servers die op verschillende distro's draaien, voornamelijk CentOS, Redhat en Debian. Debian 'wint' meestal met patch snelheid.
Security fixes worden, zoals Blokker_1999 schrijft, door Debian zelf gepatched of gebackport.
Gemaakt door mensen, gekraakt door mensen. Niet OF, maar _wanneer_.
Niet helemaal correct. Er is geen enkele reden waarom een DNS server reguliere expressies support nodig heeft voor reguliere expressies..
Het is niet omdat een product populair is, dat het ook onveilig is. *nix software domineert al jaren op verschillende markten en toch zijn zij daar niet altijd het grootste slachtoffer. Neem nu de webserver markt. Hoewel Apache al sinds jaar en dag de populairste webserver is zie je toch echt meer geslaagde aanvallen op het veel minder gebruikte IIS.

En ja, alles is te kraken, dat weten de meeste linux gebruikers gelukkig zelf ook. En zelfs op mijn linux bak laat ik regelmatig een AV scan lopen om zeker te zijn dat er niets binnenkomt. Maar daar waar MS of Apple soms weken nodig hebben om met een patch te komen en daar waar MS nog 1 keer in de maand met een patchronde komt en zelfs patches durft achterhouden omdat men eerst zeker wil zijn dat de amerikaanse overheid zijn systemen opgelapt heeft voordat een zwakte bekendraakt heb je bij open software soms al binnen enkele uren een patch en meestal binnen de twee dagen.
AV is schijnveiligheid voor consumenten. ;)

Als je begint over AV dan heb ik wel idee wat je kennis is op dit gebied. Kan je verzekeren AV geeft je geen enkele garantie of zekerheid dat je systeem niet is gekraakt! Leuk voor consumenten die verder geen verstand hebben van beheren van systeem, maar totaal geen zekerheid.

Edit/
Open software kan ook elke hacker inzien en code dus analyseren, net zoals eerlijk mensen zijn kwaadwillende dus ook instaat om code te doorzoeken naar fouten en die zullen ze niet melden uiteraard. Als eerlijk mensen fouten vinden zullen kwaadwillende ook fouten vinden, is beetje dom om te denken dat open source veiliger is dan gesloten.

Gesloten code kan juist veiliger zijn, met nadruk op kan want beide gevallen kan je niks met zekerheid zeggen, je kan het niet allemaal op 1 hoop gooien. Zal altijd per code verschillen en hoeveel geluk de hackers hebben bij het achterhalen van functie in gesloten code.

[Reactie gewijzigd door mad_max234 op 28 maart 2013 18:56]

Toch heb ik meer vertrouwen in een populair Open Source dan in een populair closed source en wel hierom:
  • Geschiedenis leert ons dat ontdekkingen vaak gelijktijdig worden gedaan, wanneer een kwaadwillende iets ontdekt is de kan reŽel dat goedwillende het ongeveer gelijktijdig ontdekken.
  • indien een kwaadwillende gebruik maakt van een exploit (mits dit misbruik wordt ontdekt) dan zal bij OS sneller een patch plaats vinden
T.a.v. AV, dat is beter dan niets doen. Je verkleint de kans dat je slachtoffer wordt van veelvoorkomende minder geavanceerde virussen. Maar ik ben het met je eens, het geeft geen absolute zekerheid. Dat is wat stuxnet en zijn varianten ons geleerd hebben.
Niets bied 100% zekerheid, maar het geeft je meer zekerheid dan helemaal niets te doen. Natuurlijk zal er een periode zijn na de release van een nieuw virus waarin dit niet word herkend door de virusscanner (tenzij de heuristics het alsnog opmerken), maar vanaf dat een virus door 1 AV bedrijf word opgemerkt is het een kwestie van uren voordat het in de lijst met definities beland. En vanaf dat moment ben je met een actieve AV scanner wel veiliger af dan zonder..

En nee, idd, OSS is niet veiliger dan closed source. Het zal waarschijnlijk evenveel ernstige lekken bevatten als closed source tegenhangers. Maar de OSS wereld heeft al wel aangetoond dat ze er op een zeer volwassen manier mee omspringen en over het algemeen een stuk sneller security fixes kunnen pushen dan grote closed source bedrijven.
Klopt, maar wat heeft dat met BIND of dit artikel te maken? Je schrijft alsof het nieuw is dat BIND een doelwit voor onderzoekers en hackers is. BIND is echter al decennia lang een bekend doelwit, met in het verleden enkele ernstige kwetsbaarheden.
Onzin. Tot nu toe is, ondanks de populariteit, iOS nog steeds het veiligste smartphoneplatform. Windows/MS aanhangers roepen altijd zo hard dat het door de populariteit komt, maar dat is niet zo. Er is op ieder platform iets te halen. Het hacken van webservers is commercieel ook heel interessant. Waarschijnlijk nog wel interessanter dan jouw saaie persoonlijke desktopje met vakantiefoto's en mp3's. De mogelijkheden zijn eindeloos, van botnets tot het hacken van de sites die er op draaien tot het misbruiken van de bandbreedte en always-online eigenschap. En toch pakken ze die desktop, omdat die veel simpeler te breken zijn dan de gemiddelde webserver.

En er staat overigens nergens dat het misbruikt wordt, alleen dat het mogelijk is. Er is een lek gevonden en gepatched. Niks te zien hier, business as usual.
Out of memory error? Is dat te vergelijken met een buffer overflow?

OT: Bestaat deze exploit dan ook nog in de 9.9.2. versie van Bind? Die is namelijk de 25ste pas uitgekomen. Vind het persoonlijk raar dat ze nu die bug nu pas vinden, aangezien die andere versies al wel behoorlijk oud zullen zijn.
@BAtiatus
De fout zit niet in BIND maar in de libregexp die gebruikt word ten tijde van compilatie van de BIND source naar de BIND executable.
Dat is wel raar. Want dat zou impliceren dat het niet per se hoeft voor te komen bij de bind versies die in de distributies zitten.
Voor zover ik weet distribueert Bind uberhaubt geen binaries, alleen maar source.
Hierdoor kunnen aanvallers niet alleen dns-servers offline halen maar ook andere applicaties op de server benaderen.
Uit de advisory van ISC kan ik alleen een DoS mogelijkheid halen, niet dat je bij de rest van de server zou kunnen komen.

Desalniettemin is het altijd een goed plan om je services in constructies zoals FreeBSD jails te draaien.

edit: men kan ook andere applicaties op dezelfde server offline halen door het geheugen vol te laten lopen. Het benaderen van andere applicaties lijkt hier niet aan de orde. Belangrijk detail :)

[Reactie gewijzigd door Sfynx op 28 maart 2013 22:11]

Hoe bekijk je of je uberhaupt affected bent met je bind:

ldd /usr/sbin/named | grep regex

Komt hier een libregex o.i.d. tevoorschijn, kun je het beste recompilen zelf van bind zonder libregex ;)

Op dit item kan niet meer gereageerd worden.



Populair: Desktops Vliegtuig Luchtvaart Crash Smartphones Laptops Games Apple Besturingssystemen Rusland

© 1998 - 2014 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013