Ik raad iedereen aan om deel 1 en deel 2 van deze serie te lezen voor achtergronden en context. Zoals ik besproken in deel 1 stel ik de claim van Mozilla dat Firefox lang niet zoveel veiligheidsproblemen kent als Microsofts's Internet Explorer aan de kaak met een IE en Firefox kwetsbaarheidsanalyse. Dit resulteerde in een een weerlegging van mijn betoog door Mike Shaver van Mozilla (lees dit alsjeblieft zodat je zijn punt snapt).

Mijn grootste probleem met zijn verhaal is dat hij in plaats van het bekijken van software-risico's het onderwerp verandert en wegleidt van Firefox in de richting van Microsoft. Hij beweert dat mijn analyse van beveiligingsfouten een slechte veiligheidsmaatstaf is. Uiteraard negeert hij daarbij dat het een erg goede maatstaf is om specifieke claims over lage kwetsbaarheidsaantallen te weerleggen.

Ik denk nog steeds dat er een hevige en open discussie moet ontstaan over het genoemde onderwerp.Vandaag zal ik op een van de twee hoofdpunten van Shaver ingaan. Hij zegt namelijk: "Je kunt alleen maar tellen wat de softwaremaker je wil laten zien."

Je kunt allen maar tellen wat de softwaremaker je wil laten zien

Ik zou eerder zeggen dat je alles kunt tellen dat breed bekend is bij het publiek en dat aan het licht is gekomen door veiligheidsexperts en softwaremakers. Dit is de speerpunt van de 'full disclosure' theorie. Ik ben ervan overtuigd dat de meeste kwetsbaarheden in gesloten en open source-modellen aan het licht worden gebracht door iemand die niet voor de ontwikkelaar of de verkoper van de software werkt.Via die weg komen er wel problemen naar buiten maar het is slechts een klein aantal van de kwetsbaarheden.

Als dat waar is waarom wordt dit dan aan de kaak gesteld? Waarschijnlijk omdat er zogenaamde 'stille reparaties' een heikel punt waren een paar maanden voor mijn analyse uitkwam. Na dit een tijdje bestudeerd te hebben zie ik het als een incarnatie van de vele interpretaties die aan de volledige openheidsregel worden gegeven. Daarnaast is het een voortzetting van het debat tussen verschillende kampen.

- (positie een) Volledige openheid vereist dat er volledig en gedetailleerd naar buiten wordt gebracht wat de kwetsbaarheden zijn, inclusief hoe die te detecteren en exploiteren zijn.

- (positie twee) Het proces van openheid, en de beslissing welke informatie moet worden vrijgegeven, moet erop gericht zijn om het risico van gebruikers te minimaliseren. Ik voeg hier ook de 'maak zo weinig mogelijk openbaar' groep aan toe.

Ik neig meestal naar de tweede optie want als die succesvol gebruikt wordt resulteert dat in minder risico voor gebruikers. Maar voor dit artikel zal ik proberen in te gaan op de positie die Mozilla inneemt en probeer ik te bekijken hoe die punten standhouden:

"We tellen elk apart defect. We tellen de fouten die Mozilla-ontwikkelaars zelf vinden. We tellen de dingen dingen die we ondernemen om defecten in andere software te verhelpen, inclusief Microsoft en plugins van andere partijen. We tellen geheugengedrag waarvan we denken dat het een risico kan zijn, zelfs als er nooit bewijs is geleverd dat dat risico ooit is misbruikt, ook als we het probleem binnenshuis wordt vastgesteld." (uit 'Tellen is nog steeds makkelijk')

Daar is de claim: ze tellen elk apart defect. Zover ik weet heeft Mozilla nooit enig rapport of 'telling' gepubliceerd, maar daar ga ik niet over bekvechten. laten we het in plaats daarvan interpreteren alsof ze zeggen dat ze toegeven alle kwetsbaarheden van Firefox te tellen en bekend maken zodat die ook makkelijk geteld kunnen worden.

Check #1 Telt mozilla alle kwetsbaarheden?

Ok, ik begin met een simpele check op hoog niveau. Een lijst met kwetsbaarheden die werden toegegeven en gerepareerd door de Mozilla Foundation Security Advisory (MFSA). Daarvan stel ik mijn 'Mozilla heeft het veiligheidrisisco toegegeven' lijst samen.

Vervolgens stelde ik een lijst samen aan de hand van de NVD waarin kwetsbaarheden voor Firefox worden opgesomd, vergeleek die met de lijst van Mozilla en filterde de dubbele risico's eruit. Zo bleef ik zitten met de fouten die (nog) niet terug komen in een Mozilla Foundation Security Advisory. Daarnaast verwijderde ik alle risico's die door de NVD werden aangemerkt als

discussiepunt. Ook alle kwetsbaarheden die betrekking hadden op een beta-versie van Firefox gingen eruit. Ook de fouten die eigenlijk alleen betrekking hadden op een plugin filterde ik eruit. Zo bleef ik over met een lijst van 44 kwetsbaarheden die blijkbaar niet 'geteld' zijn door Mozilla:

CVE-2005-2114, CVE-2005-2395, CVE-2005-4685, CVE-2005-4720, CVE-2005-4809, CVE-2006-0496, CVE-2006-2613, CVE-2006-2788, CVE-2006-4310, CVE-2006-4561, CVE-2006-6585, CVE-2006-6970, CVE-2006-6971, CVE-2007-0801, CVE-2007-0802, CVE-2007-1004, CVE-2007-1084, CVE-2007-1116, CVE-2007-1256, CVE-2007-1736, CVE-2007-1762, CVE-2007-1970, CVE-2007-2162, CVE-2007-2176, CVE-2007-2671, CVE-2007-3072, CVE-2007-3073, CVE-2007-3074, CVE-2007-3827, CVE-2007-4013, CVE-2007-4038, CVE-2007-4041, CVE-2007-4357, CVE-2007-5335, CVE-2007-5415, CVE-2007-5691, CVE-2007-5896, CVE-2007-6715, CVE-2008-0367, CVE-2008-2419, CVE-2008-2786, CVE-2008-3444, CVE-2008-4324, CVE-2008-4723

Het zou zo kunnen zijn dat de problemen in de toekomst nog verholpen worden en dan pas geteld worden. Zelfs als dat zo is zal dat hun eigen risicokaart overhoop gooien (zie deel twee voor meer info). Dit komt doordat slechts 1 van die problemen publiekelijk is erkend voor 100 dagen en slechts vijf publiek bekend zijn voor minder dan een jaar. Dan is er natuurlijk nog de optie dat sommige kwetsbaarheden stilletjes geplakt zijn. Maar dat lijkt onwaarschijnlijk aangezien Mozilla de volgende regel formuleerde:

"Het is algemeen bekend dat Microsoft de release notes voor service packs en bundle fixes redigeert, soms betekent dit dat er slechts 1 kwetsbaarheid wordt geteld terwijl er bijvoorbeeld zeven defecten worden verholpen." (ook uit 'Tellen is nog steeds simpel')

Ik denk dat ik veilig kan stellen dat dit statement betekent dat Mozilla heel erg tegen stille reparaties is. Laten we eens zien of we aan wat Kritisch Denken kunnen doen en de vinger op de zere plek kunnen leggen.

Check #2 Zijn er gevallen van verschillende Mozilla kwetsbaarheden die 1 keer meetellen?

Ik kan makkelijk nagaan of er CVE-identifiers zijn die door Mozilla zijn gebundeld tot een enkele. Ik ga niet het onderste uit de kan halen maar doe gewoon wat basisonderzoek en ik kijk wel wat ik vind:

- MFSA 2008-69—Lists CVE-2008-5513 wordt als gerepareerd aangemerkt maar 'een variant kan gebruikt worden' dat betekent dat er tenminste twee risico's waren. De SessionStore XSS -gevaren link geeft aan dat er vier bugzillatopics zijn aangemaakt, maar ik kan niet in detail treden omdat ik geen toegang krijg.

- MFSA 2008-68 / CVE-2008-5512—Geciteerd van de NVD, "Verschillende onspecifieke kwetsbaarheden in Firefox 3.x—"

- MFSA 2008-52 / CVE-2008-5016—Geciteerd van de NVD, "Stelt aanvallers in staat om een denial of serviceaanval uit te voeren via verschillende vectoren." Daarnaast staan er 11 bugzilla rapportages genoteerd die geassocieerd worden met hetzelfde probleem.

- CVE-2008-4064, CVE-2008-4063, CVD-2008-4062—Geciteerd van de NVD, "Verschillende onspecifieke kwetsbaarheden in Firefox."

- CVE-2008-2798, CVE-2008-2799—Geciteerd van de NVD, "Verschillende onspecifieke kwetsbaarheden in Firefox." Het lijkt erop dat hier drie bugzilla rapporten over zijn aangemaakt.

- CVE-2006-6505—Geciteerd van de NVD, "Verschillende heap-based buffer overflows."

- CVE-2006-5464—Geciteerd van de NVD, "Verschillende onspecifieke kwetsbaarheden in de layout-engine van Firefox."

Dat zijn waarschijnlijk genoeg voorbeelden om een punt te maken. Er zijn nog veel meer voorbeelden maar ik ben er niet verder op in gegaan. In elk van deze gevallen bestaat de kwetsbaarheid uit verschillende problemen die onder 1 noemer worden geschaard. Ik denk dat een accurate beschrijving van deze gevallen zou zijn dat er verschillende risico's samen worden gevoegd. Dat klinkt u vast bekend in de oren?

Ik verwacht dat Mozilla gaat zeggen dat ze transparant zijn omdat hun bugrapporten doorzoekbaar zijn, maar dat lijkt me triviaal. Een van de grootste kritieken op stille reparaties is dat de gaten nog steeds makkelijk te vinden zijn voor diegenen die weten hoe ze een update ongedaan moeten maken. Aanvallers zouden dan 'exploits schrijven voor alle kwetsbaarheden, zonder acht te slaan op op het rapport'. Deze zorg moet ook in dit geval serieus worden genomen. Het antwoord op de hamvraag lijkt in deze zaak duidelijk. Het lijkt er op dat Mozilla verschillende varianten van gaten plakt en die onder 1 noemer schaart.

Check #3 Voert Mozilla stille reparaties uit in nieuwe versies?

Er is een laatste probleem dat Mozilla stelt in 'Tellen is nog steeds simpel': "Of misschien hoor je er helemaal niets over omdat het samen met SP2 kwam en ze er helemaal geen ruchtbaarheid aan gaven." Is het slecht om kleine veiligheidsproblemen op te lossen in de minder vaak uitgebrachte service packs? ik denk er het mijne van. Uit dat commentaar maak ik op dat Mozilla dit gedrag van anderen afkeurt.

Ik heb de kwetsbaarheidslijst van hierboven gegroepeerd voor elke Firefox-versie die niet meer ondersteund wordt. Geen van deze fouten worden aangehaald in een MFSA die ik kon vinden. En ze zijn allemaal gepubliceerd voordat een versie ophield te bestaan. Wat is er gebeurd met deze risico's? Ik verwacht geen patches voor deze gaten omdat de browsers niet meer ondersteund worden. Maar de basiscode wordt nog steeds gebruikt in de nieuwe versies.

Er komen drie logische mogelijkheden in me op:

- De code werd niet meegenomen naar de volgende versie en vervangen. Dit zou in principe een reparatie zijn.

- Het gat werd stiekem gerepareerd. Bij CVE-2007-3072 lijkt dit het geval te zijn. er is bijvoorbeeld geen MFSA, maar de NVD heeft een link naar de bugzilla lijst.

- Het gat bestaat nog steeds. CVE-2006-4561 en CVE-2007-1736 lijken daar voorbeelden van te zijn.

Wellicht wil je er zelf nog even naar kijken en zijn deze fouten inmiddels opgelost maar kon ik daar gewoon het bewijs niet voor vinden. Stilletjes gerepareerd? Niet gepatcht? In ieder geval lijkt het op de beslissing die Mozilla gebruikte om in het eerste jaar van Firefox de aandacht op iets anders dan de lekken te richten.

Laat me er op wijzen dat ik geen enkele claims maak maar eenvoudig de beweringen van Mozilla test. Zij beweren dat Firefox 'de veiligste webbrowser' is. Ik denk dat deze resultaten voor zich spreken. Het is waar dat je alleen kunt zien wat de ontwikkelaar wil dat je ziet, dit heeft ook betrekking op Mozilla. Die in plaats van hun boude taal blijkbaar verschillende reparaties op 1 hoop gooien en daarnaast stille reparaties uitvoeren als dat zo uitkomt in hun ontwikkelproces.

Zijn deze beslissingen onredelijk? Waarschijnlijk niet. Het benadrukt voor mij iets dat ik in de afgelopen jaren vaak in de wandelgangen heb gehoord -veiligheid verbeteren is niet alleen moeilijk voor Microsoft, maar voor de hele industrie.

Er is nog een groot punt in 'tellen is nog steeds simpel'. "Meer reparaties betekent minder veiligheid?" Met die stelling kan bedoeld worden dat door in 2006 minder kwetsbaarheden te plakken Mozilla's beveiliging beter was dan in die van Internet Explorer. Als dat zo is verwacht ik een neergaande trend voor Firefox in 2007 en 2008 (ze waren immers rigoureuzer met het repareren van kwetsbaarheden in 2006). Aan de andere kant zien we dat de trend niet neergaand, dat trekt de regel weer in twijfel.

Jeff Jones is security director bij Microsoft's Trustworthy Computing group. Jeff heeft jarenlange beveiligingservaring en werkte met het interne beveiligingsteam van Microsoft en veel Chief Security Officers uit het bedrijfsleven. Hij doet onderzoek om praktische en meetbare resultaten over beveiliging te krijgen waarmee de beveiliging van Microsoftprogramma's en processen verbeterd worden. Vertaling: Loek Essers. Bron: CIO.com