Grote onzin. Ten eerste kun je ze niet testen want dan moet de malware eerst bekend zijn. Ten tweede, zul je altijd voordat je langs virusscanners wilt gaan eerst "ervoor" moeten gaan staan. En dan is schieten wel raak.

Niet gecopy-paste uit het artikel van The Register (die lijkt te zijn overgenomen):

"Still, the exploit has its limitations. It requires a large amount of code to be loaded onto the targeted machine, making it impractical for shellcode-based attacks or attacks that rely on speed and stealth. It can also be carried out only when an attacker already has the ability to run a binary on the targeted PC."

Oftewel, de praktische uitvoering van de exploit is niet zo ernstig als zonder deze copy-paste sectie.

Bron: http://www.theregister.co.uk/2010/05/07/argument_switch_av_bypass/

Sorry hoor heren. Maar dit is zo goed als een direct copy/vertaling van het artikel op "The Register" (http://www.theregister.co.uk/2010/05/07/argument_switch_av_bypass/). Klinkt misschien wat bot maar als jullie geen toegevoegde waarde hebben aan het artikel is het dan niet beter om enkel een referentie te posten?

Jammer voor beveiligingsbedrijf Matousec...

http://www.wilderssecurity.com/showpost.php?p=1673813&postcount=75

Volledige tread:http://www.wilderssecurity.com/showthread.php?t=271968

Tsja, vind de titel nou niet echt getuigen van smaak; KHOBE 8.0 Earthquake ??? (aardbeving in Kobe, Japan)

Suggesties voor de volgende rapporten;
Katrina Hurricane 5 Report
Ground Zero-Day Malware Report
Asean NT-Bug Tsunami Report
Hiroshima Host-Based Intrusion Bomb Report

Valt in ieder geval wel op...

Ik ken het artikel verder ook niet, zo ook de research/copier niet....

Maar zou de klemtoon niet moeten liggen op het feit dat het oude probleem opeens een bedreiging is geworden omdat er zo'n groot aantal MULTI-CORES op de markt zijn die er in 2003 nog niet zoveel waren. De doelgroep is misschien vandaag groter geworden waardoor het voor inbrekers nu rendabeler is als toen? Ja, het artikel is wellicht gekopierd, maar met de toevoeging van de multi-cores (waarbij timing minder belangrijk wordt er kan immers een andere thread opgestart worden) is het originele artikel wel in een nieuw daglicht geplaatst???

Nogmaals, ben geen expert. Enkel gezond boerenverstand.


Het Orakel

Hier struikelde ik even over. De goedaardige code zou een kwaadaardige lading aanroepen net voor hij zelf uitgevoerd wordt? Code kan tijdens zijn uitvoering iets aanroepen, net daarvoor doet die code helemaal niets.

Het Register-artikel waar DamnSecure hierboven naar linkte is duidelijker: de goedaardige code wordt gescand, en in het korte moment tussen goedkeuring en daadwerkelijke aanroep van de goedaardige code overschrijft een andere thread hem met kwaadaardige code, zodat die wordt uitgevoerd terwijl de virusscanner niet beter weet of er staat iets goedaardigs.

Die kwaadaardige code is dan vermoedelijk als een blok data geladen, die op het moment van laden onherkenbaar is voor de virusscanner en in geheugen weer in code wordt omgezet.

De noodzaak om net in dat korte moment de code te overschrijven, in plaats van ruim voor de aanroep, kan denk ik alleen maar betekenen dat de genoemde hooks de aanroep van de code zelf onderbreken, zodat de virusscanner tijdens de uitvoering van programma's brokjes code zo kort mogelijk voor uitvoering kan controleren. Dat gaat veel verder dan scannen op het moment dat code van schijf wordt gelezen, en als dit inderdaad zo werkt kan dat verklaren waarom sommige virusscanners de uitvoering van programma's zo kunnen vertragen.

Maar is het met moderne hardware en besturingssystemen niet mogelijk om codesegmenten onoverschrijfbaar te maken, ook voor het proces zelf? Laad de code, maak hem read-only, voer de scan uit en roep hem aan. Niemand kan er nog tussen komen, het blok code is immers niet meer overschrijfbaar. Ik neem aan dat ik nu iets te optimistisch ben over de mogelijkheden, anders was dit vast ook wel zo gedaan. Aanpassingen aan code kunnen in een ontwikkelomgeving nodig zijn om bijvoorbeeld breakpoints te plaatsen tijdens het debuggen. Maar is er een reden waarom dat bij normaal gebruik van software ook zou moeten kunnen? Ik zou denken dat het onwenselijk is dat het gebeurt, je wilt bijvoorbeeld dezelfde code niet meerdere keren in geheugen laden als er meerdere instanties van een programma worden uitgevoerd. Met een strikte scheiding van code en data kan dat, en op de mainframesystemen waar ik vroeger op werkte gebeurde dat ook (in ieder geval binnen CICS). Maar voor hedendaagse pc-architecturen en -besturingssystemen schiet mijn kennis tekort. Is er iemand die hier zijn licht over kan laten schijnen?

Grootste rampen uit de geschiedenis van de mens:
Hiroshima `45
Vietnam `69
Chernobyl `86
Windows `95
Office `97
Windows `98
Windows `2000

Dit slaat nu nergens op mens.

Door het gebruik van Windows opzich lopen mensen al een groot beveiligingsrisico. Of dit nu ligt aan de hoeveelheid gebruikers en/of aan de zielige beveiligingsmodellen, het is helaas al jaren een feit.
En de zogenaamde beveiligings-tools maken het helaas niet beter:
- ze vertragen systemen
- vergroten (blijkbaar) het aanvalsoppervlak van een systeem
- beschadigen het systeem door b.v. systeembestanden als malware aan te merken
Anoniem schaart Windows onder de grootste rampen van de mensheid.
En dat is terecht, als men de miljarden schade ziet die de wereld jaarlijks oploopt door het gebruik ervan.

En als er Linux ofzo gebruikt was dan was er nooit zoveel schade geweest zeker? Dream on..

Dit article bevat een fout, tenminste, Symantec staat hier NIET tussen

http://www.matousec.com/info/articles/khobe-8.0-earthquake-for-windows-desktop-security-software.php#table-of-vulnerable-software

[admin] Van wie is Norton Internet Security 2010 .... [/admin]

Als HIPS aanstaat (wordt sowieso al aangeraden) werkt de aanval niet op Sophos.

http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use

Wat feitelijk een race conditie is.

http://en.wikipedia.org/wiki/Race_condition

http://www.sophos.com/blogs/duck/g/2010/05/11/khobe-vulnerability-earth-shaker/