Ja, want een update installeren met een fix waarvan totaal niet bekend is wat het fixt omdat er totaal niets bekend is van wat het lek nou precies is, is ook bijzonder secure om te installeren !
Er zijn niet voor niets zo weinig systemen "gepatcht". Zolang men niet weet wat er precies loos is en wat de fix nou precies fixt is ook het installeren van de patch een security risk waardoor er heel wat mensen zijn die het uitstellen. Er zijn inmiddels al wel vermoedens geplaatst wat het lek nou zou kunnen inhouden maar meer dan dat weten we nog niet. Je zou in dat opzicht dus kunnen beredeneren dat de rest van de wereld zich zou moeten schamen omdat ze klakkeloos een of andere fix die een lek dicht waarvan helemaal niets bekend is overneemt en doorpusht.
In deze geldt de veelvuldig gemaakte uitspraak "wat is wijsheid?".
Buiten dat zijn de systemen van Apple hoofdzakelijk desktopsystemen. Ik ben nog geen desktop tegen gekomen die een DNS server draait. Enige wat je op de desktopsystemen vindt zijn dingen als BIND tools zodat je tools als dig, host, etc. tot je beschikking hebt. Voor dat soort systemen is zo'n bug een minder big deal dan bij een DNS server. Om die reden waren een aantal fabrikanten/softwarebouwers/distrobouwers (of hoe je het nog meer noemen wilt) ook niet zo heel rap met het uitbrengen van een update, afgezien van het eerder genoemde verhaal.
Overigens zijn er wel meer mensen geweest die net als mensoc het nogal een schande vonden dat fabrikant x er "zo lang" over deed om die patch uit te geven. Jammer dat die mensen er niet even bij stil staan dat er nog zoiets bestaat als kwaliteit en dat er toch heel veel fabrikanten het nodige willen checken om de kwaliteit geen geweld aan te doen. Dat er wat onverlaten zijn die kwaliteit maar iets sufs vinden betekent niet dat de rest van de wereld die houding ook maar moet aannemen want dan gaan er wel heel vaak, heel veel dingen stuk.
@hieronder: Dan Kaminsky heeft de details niet beschikbaar gemaakt dat is waar ik op doel, niet dat het lek onbekend was. Om dat er geen details beschikbaar zijn van de lek maar er wel een of andere patch is maakt dat het interpreteren van die patch lastig. Wat doet die patch nou eigenlijk en is het wel zinvol wat het doet, is het niet stiekem iets kwaadaardigs wat het doet? Je weet de details van het lek niet dus kun je niet checken of de patch ook echt datgene patcht wat het zegt dat het patcht. Dat is wat het tot een security risk maakt en dat deel van mijn post heb je kennelijk dus niet begrepen.
Daarnaast zijn er wel vaker bedrijven geweest die als laatste een patch uitgaven (tja, iemand moet de laatste zijn) en dat soms ook heel wat later dan de rest deden. Dat kan gebeuren om diverse redenen. Als je een patch hebt wil je graag weten wat het precies doet en wat voor gevolgen het heeft. Je zult dus het e.e.a. moeten gaan testen. Als je dan je eigen patch gemaakt hebt moet dat ook weer getest worden. In dat hele proces moet je je er wel zeker van zijn dat er niet stiekem andere onderdelen zijn die ook invloed hebben of hinder van de bug danwel de patch ondervinden. Dat kan bij sommige dingen wat langer duren omdat het wat complexer of onduidelijker is. Soms is het ook gewoon een onderschatting van het probleem en heel soms is het gewoon luiheid.
Het is mij gewoon te makkelijk om bij dit soort problemen een fabrikant het zwaar aan te rekenen dat ze als laatste zijn of dat ze later dan de rest reageren. Zeker als je niet precies weet wat er nou aan de hand is omdat de details achtergehouden worden is het een hele verstandige beslissing om gewoon de kat uit de boom te kijken of zelf onderzoek te doen naar het probleem. Dat kost nou eenmaal wat meer tijd. Verhaaltje is van toepassing op allerlei bedrijven van vliegtuigbouwers tot softwarebouwers.
Buiten dat is het niet specifiek een bug, dat cache poisoning is onvermijdelijk aangezien DNS ontworpen is zonder dat men uberhaupt aan security dacht. Tegenwoordig is daar al weer sinds jaren een oplossing voor in de vorm van DNSSEC. Je kunt dus eerder een heleboel bedrijven gaan lopen blamen dat ze geen DNSSEC implementeren terwijl ze toch de mogelijkheid hebben (BIND en bijv. NSD supporten DNSSEC alweer een tijdje). Het probleem is wat groter dan alleen deze bug en dat men geen DNSSEC implementeert is eigenlijk veel zwaarder aan te rekenen.
EDIT: kwam ook nog een artikel van ZDNet Australia tegen die demonstreert waarom snel patchen niet erg slim kan zijn:
DNS patch causes BIND blunder.
[Reactie gewijzigd door ppl op 24 juli 2024 14:08]
:fill(white):strip_exif()/i/2000986561.jpeg?f=thumbmedium)
:strip_exif()/i/1198321391.png?f=thumbmedium)
/i/1211457875.png?f=fpa)
/i/1263287364.png?f=fpa)
:strip_exif()/i/1159122962.gif?f=fpa)
/i/1198494081.png?f=fpa)
/i/1218281732.png?f=fpa)
:strip_exif()/i/1216747549.gif?f=fpa)
/u/28121/avatar_kleiner.png?f=community){kind=avatar}
/u/4024/burne.png?f=community){kind=small}
kunnen zijn die dit loopt uit te testen op mij./u/214894/crop5baaa31f9c4ff_cropped.png?f=community){kind=small}
/u/62384/crop61891f444d6e9.png?f=community){kind=small}
/u/229564/eic.png?f=community){kind=small}