Ik lees vooral "fingerprinting"

Of is privacy ondergeschikt aan security?

Ik vraag me wel af of dit geen nachtmerrie wordt voor de beheerders. Hebben al die verschillende versies dan ook hun eigen problemen? Die bij geen enkele andere gebruiker gerproduceerd kunnen worden? Dat wordt nog lachen dan... :).

Ik heb zelf geen ervaring met NVP (N version Programming) applicaties of systemen. Maar het klinkt mij als 2 apparte implementaties van dezelfde functionaliteit die door 2 (of X) verschillende teams wordt onderhouden. Hoe gaat dit met miljoenen versies? Is er iemand die nog kan achterhalen wat precies de verschilen en overeenkomsten zijn tussen deze versies? Of wordt het blind trail en error op miljoenen variaties?

Een snelle google leerde mij ook: http://www.hillside.net/plop/2009/papers/Process/N-Version%20Programming.pdf
The assumption is that when a latent fault activates in one version then the other versions of the system that do not contain the same fault. Research by Knight and Leveson [KL86][KL90] has shown that the assumption of independence between the faults produced by the different design teams does not hold.

Het schijnt dat verschillende programeurs dezelfde manieren en technieken toepassen ;)

Mag dit wel? In vele EULA's staat dat software modificatie en/of reverse engineering verboden is.

En als de software in een appstore wordt gewijzigd, hoe weet je dan of er niet mee is geknoeid? (anders dan de door hun bedachte methode).
Je kan immers nooit meer de hash van de download controleren.

En hoe zit het met de support van de ontwikkelaar?
Je werkt immers met een niet-originele versie.

Uiteindelijk zullen verschillende versies dezelfde code uitvoeren. Deze code blijft dan nog steeds de Target voor malware. Flauwekulartikel als je het mij vraagt.

Dat was het al vanaf het moment dat de eerste vinger werd gegeven...

Dit is niet echt diversiteit die zoden aan de dijk zet, maar wel een hoop gedoe gaat opleveren. Patches werken niet meer, bijvoorbeeld. Debug dumps (zoals wel stilletjes teruggestuurd bij crashes) blijken onnavolgbaar geworden. Dat soort werk.

De grap is dat het best werkt voor virussen, en "polymorphism" bestaat dan ook al tientallen jaren in dat wereldje, met af en toe iemand die het wiel opnieuw uitvindt. Het werkt daar wel omdat ze zich verdedigen tegen detectie, waar een signatuur subtiel wijzigen ineens betekent dat'ie niet meer in de lange "zwarte lijst van slechtheid" in je virusscanner voorkomt.

Maar voor programmas? Die moeten zich verdedigen tegen misbruik van fouten in de eigen code, je weet wel, buffer overruns, injecties, remote code execution, of zoiets als heartbleed. Als je de code subtiel veranderd helpt dat niet zo erg. Wellicht dat ik heel erg achterloop en dat op mobiele platformen de virussen zich ondertussen ook als scanner gedragen om slachtofferprogrammas te vinden, en wellicht dat het dan helpt. Maar anderszins? Niet zo erg veel, nee.


Wat ik wel onder diversiteit versta is als niet 95%+ een enkel (notoir brak) en hetzelfde besturingssysteem op dezelfde architectuur gebruiken. Je zorgt dat er minstens twee, liefst wat meer besturingssystemen elk een redelijk vergelijkbaar marktaandeel hebben (elk minstens 1/(N+1)de deel, zeg), en dat dan weer elk op elk van liefst twee, liefst een paar meer verschillende architecturen met compleet andere instructiesets. Als je je programmas netjes opzet hoeft ontwikkelen voor zo'n verschillende bomenbos geen probleem te zijn, sterker, je krijgt er robuustere programmas door.

Deze technieken worden al tijden gebruikt door malware om op fingerprint gebaseerde anti-malware pakketten te foppen. De 'truuk' is dat het initiële pakket dat gedownload wordt hetzelfde kan zijn (de hash is dus hetzelfde), maar bij het daadwerkelijk installeren zijn er diverse alternatieven voor dezelfde code waar random tussen gekozen wordt. Omdat deze code uiteindelijk ook op assembler niveau verschilt maakt dit het lastig voor malware die ook op basis van fingerprinting werkt.

Dit zal echter maar tijdelijk helpen omdat meer en meer malware gebruik gaat maken van ROP aanvallen waartegen dit soort maatregelen ook niks gaat helpen. Je zal dan echt (hardwarematige) flow control moeten gaan inbouwen.

Op het niveau van de programmalogica zoals een programeur die in een hogere programmeertaal noteert zal niets aangepast worden door zo'n systeem. Maar op machinetaal-niveau verandert er kennelijk wel van alles. Misbruik van logicafouten in de programmatuur zal dus niet ondervangen kunnen worden, maar als malware die de werking van een app wil beïnvloeden niet meer kan herkennen waar die zichzelf moet injecteren in de machinecode omdat die op elke smartphone anders is, of als het effect ervan onvoorspelbaar wordt voor de malwareschrijver, dan kan dit wel degelijk een leuke bescherming vormen.

Bekijk het zo: polymorfe virussen maken virusscanners het leven zuur, maar als je polymorfe applicaties maakt dan maken die op hun beurt virussen het leven zuur.

Dit kan niet elke vorm van misbruik ondervangen, maar het kan potentieel wel een heel niveau waarop zwakheden kunnen worden misbruikt onaantrekkelijk te maken voor aanvallers. Dat lijkt me winst, als je alle deuren dicht wil zetten moet je tenslotte elke deur die open staat afzonderlijk sluiten.

Het idee dat diversiteit robuuster is is op zich niet nieuw. Op een ander niveau betekent het dat je beter kan standaardiseren op communicatieprotocollen, bericht- en bestandsformaten dan op specifieke software. Dat komt helaas lang niet altijd goed van de grond. Er zijn commerciële leveranciers die op supplier-lockin aansturen door bewust niet volledig compatibel te zijn met anderen; er zijn ontwikkelaars die alleen de inefficiëntie zien van het opnieuw ontwikkelen van iets dat al bestaat maar niet herkennen dat diversiteit in implementaties ook belangrijke voordelen biedt; en er zullen nog wel meer oorzaken aan te wijzen zijn. De aanpak die in dit artikel beschreven wordt probeert een deel van die diversiteit op een laagdrempelige manier mogelijk te maken. Ik weet niet of het succesvol zal zijn, maar de poging is zeker interessant.

Het idee is wel goed. Door standaardisatie kunnen infecties op grote schaal voorkomen worden.

Ook al blijft de code van de software hetzelfde, op zijn hoogst andere method en class benamingen met polymorfism, met zoiets simpels als het Windows registry dat afwijkt werkt een groot deel van de standaard malware al niet meer. Met zoiets simpels als een systeem DLL met een andere naam kan ook veel gewonnen worden. Maar het blijft een kat en muis spel want die bestanden moeten dan weer ergens genoemd worden om ze uberhaupt nog door het systeem te laten vinden, en dat kan een malware weer opzoeken.

Maar als ik mij niet vergis zijn de virussen zoals die vroeger een executable infecteerde (door zichzelf te repliceren naar het einde van een bestand en te refereren in het begin van de executable) op hun retour.

Correctie van mezelf hierboven
"Door standaardisatie kunnen infecties op grote schaal voorkomen worden."
Moet zijn:
"Door minder standaardisatie kunnen infecties op grote schaal voorkomen worden.

Als er VS13 gebruikt wordt niet, dan is IL de tussenschakel. Tenzij er 100% assembly gebruikt wordt, maar dit is niet geschikt voor de wat grote en gecompliceerdere apps.

We hadden al zelf modificerende malware. Zelf modificerende gebruikersprogrammatuur lijkt me een logisch gevolg.

Shooting at a moving target.

Zelf denk ik dat veilig programmeren er niet eenvoudiger op wordt. De codebase wordt groter. En meer coderegels heeft als logisch gevolg meer fouten. En grotere complexiteit idem dito.

Daarnaast is de kans zeer wel aanwezig dat het werk van AV-programmatuur nagenoeg onmogelijk wordt, want het schimmige gedrag van malware kopiëren naar reguliere programmatuur zorgt ongetwijfeld voor een stortvloed aan false positives.