hoe groot is de kans dat eenzelfde lek in 4 verschillende operating systems hetzelfde werkt, zonder dat de fabrikant hier niet vanaf weet?

De fout klinkt als een soort heartbleed. Misschien ligt dat ook wel aan de basis.

En als het lek zit in een gemeenschappelijke library welke op alle typen firewalls gebruikt wordt, dan is de kans klein dat de fabrikant het weet.

Veel belangrijker:
- is dit een bug van een Cisco-programmeur of het werk van een NSA-mol?
- en als Heartbleed aan de basis ligt, waarom komt Cisco er nu pas mee?

Bij software ontwikkeling wordt altijd aangeraden om code 'reusable' te maken, en gezocht naar synergie tussen verschillende producten.
Dat verschillende producten van Cisco gebruik maken van dezelfde codebase voor een bepaalde functie (zoals IPSec key exchange) is dan vrij logisch .

Toch een beetje vreemd van een netwerkgigant met een best wel goede-kwaliteit-reputatie om zulke ernstige bugs zo lang in hun producten te hebben. Gebruiken ze geen fuzzers om hun producten te testen?

Geen idee wat Cisco wel of niet doet aan product validatie.
Alle externe experts die hiermee minimaal een heel mooi presentatie slot op Blackhat hadden kunnen scoren en een hoop credits voor hun bedrijf hebben 't ook niet gevonden.
"Gewoon een fuzzer gebruiken" was dus waarschijnlijk niet voldoende om dit te vinden.

En dit op zijn beurt laat een onsmakelijke optie open dat de exploits ontworpen zijn om niet door iteratie gevonden te worden.

Niet echt een standaard programmeerfoutje zou je denken.

Griezelig dit, zeker als je bedenkt dat de schaal inmiddels nog wel eens gigantisch kan zijn. De kwaliteit is immers zo hoog dat ze zo goed als niet gevonden worden en dus in alles kunnen zitten met een batterij of stekker.

Kom op .
Je denkt toch niet dat elke bug die een fuzzer overleeft alleen maar een bewust geintroduceert über backdoor moet zijn ?

Wellicht dat je inderdaad kunt zeggen dat de bugs die er met een fuzzer uitrollen hoofdzakelijk de standaard junior fouten zijn.
Dan nog zijn er gewoon echte bugs die maar heel zelden optreden, en alleen onder een heel bepaalde set van omstandigheden.
Die vind je 'toevallig' maar heel zelden, of ze worden gevonden (/voorkomen) bij een code review door een heel goede programmeur die een aantal stappen verder denkt.

Zo af en toe komen de voorbeelden (exotisch omstandigheden, analyse, of preventie) langs op de linux kernel mailinglist - niet specifiek security bugs, maar gewoon erg lastige bugs.
Het inzicht van de kernel toppers in zo'n thread is adembenemend.
Met die voorbeelden in het achterhoofd hoeft de "niet simpel te vinden Cisco IKE bug" dus niet bewust geintroduceerd te zijn. Het zou kunnen, maar het volgt niet uit "triggert niet simpel" .

De NSA zal wel zeer waarschijnlijk _gezocht_ hebben naar exploits. Het kost tijd en moeite, maar je kunt object code reverse engineeren en decompileren naar equivalente source code . Of het bedrijf gehacked, of simpelweg als deel van de overheid inzicht in de source als deel van een audit voor de aanschaf van apparatuur - wanneer de klant groot genoeg is kan met een leverancier over _alles_ onderhandeld worden.

Kortom - lastige bug of geintroduceerde backdoor is nog niet uit te maken.


Het is zeker zorgwekkend. Ik moet wel zeggen dat het ik altijd naïef en inconsistent gevonden heb dat in de gebruikelijke security policies een bereikbare SSH poort tot hel en verdoemenis zou leiden, en het standaard advies is om remote access met een "VPN" te beveiligen.
Waarom men zoveel vertrouwen had in een bugvrije implementatie van een extreem complex protocol als IPSec is me altijd een raadsel geweest.
Maar goed, dit (en de Juniper backdoors) is dan wel een illustratie en wakeup call dat een "VPN" evenzeer een risico is wat geanalyseerd moet worden .