image

Onderzoekers "bevriezen" software om malware te stoppen

zondag 19 juli 2015, 11:19 door Redactie, 13 reacties

Onderzoekers hebben een manier bedacht om malware op computers te stoppen, namelijk het "bevriezen" van software. De meeste software voor Windows is afhankelijk van dynamic-link libraries (DLLs). Een DLL is een uitvoerbaar bestand dat door programma's wordt gebruikt om code en andere bronnen te delen die nodig zijn om bepaalde taken uit te voeren.Windows bevat diverse DLL-bestanden met functies en bronnen die programma's nodig hebben om in de Windows-omgeving te kunnen functioneren.

Omdat een DLL-bestand allerlei gerelateerde code bevat, zal een programma dat er gebruik van maakt meer code in het geheugen laden dan het eigenlijk nodig heeft. Malware kan van deze extra code gebruik maken als het een kwetsbaarheid in de applicatie weet te gebruiken. Onderzoekers Collin Mulliner en Matthias Neugschwandtner bedachten een tool genaamd CodeFreeze die analyseert welke code een programma uit een DLL-bestand precies nodig heeft en welk gedeelte het kan missen. Vervolgens overschrijft de tool de ongebruikte DLL-code die het programma in het geheugen van de computer heeft geladen, zodat malware hier geen gebruik van kan maken.

Overhead

CodeFreeze wordt zelf als DLL-bestand aangeboden en zou voor weinig overhead zorgen. Tijdens een demonstratie bleek dat Adobe Reader met CodeFreeze een paar seconden langzamer opende dan zonder de tool het geval was. Meer dan de helft van de DLL-code die Reader in het geheugen laadde werd echter uitgeschakeld, zonder dat dit impact op het programma had. Een malware-exemplaar dat Mulliner had gemaakt en eerder nog Adobe Reader wist aan te vallen, slaagde hier na het inschakelen van CodeFreeze niet meer in.

Omdat de aanpassing van de DLL-code in het geheugen plaatsvindt en niet op de harde schijf, worden zowel progamma's als gebruikte DLL-bestanden niet permanent aangepast. De software is inmiddels getest op Windows 8.1 32-bit. Mulliner laat aan Tom's Guide weten dat hij samen met Neugschwandtner CodeFreeze aan Microsoft wil aanbieden. Uiteindelijk hoopt de onderzoeker dat Microsoft de tool gaat implementeren en dat softwareontwikkelaars hier in mee zullen gaan. Volgende maand zal CodeFreeze tijdens de Black Hat conferentie in Las Vegas worden gedemonstreerd.

Reacties (13)
19-07-2015, 11:41 door Anoniem
"Vervolgens overschrijft de tool de ongebruikte DLL-code die het programma in het geheugen van de computer heeft geladen, zodat malware hier geen gebruik van kan maken."

En dus is het geen shared library meer en wordt er meer geheugen gebruikt ?

Ik krijg eerder het idee dat betekend dat de malware een groottere payload moet hebben omdat het zelf de code moet meenemen die anders uit de shared library gebruikt kan worden.

Dit deel van het Tom's Guide artikel geeft in ieder geval aan dat extra code naladen niet kan ?:

"To prevent malware from injecting malicious code as extra DLLs, CodeFreeze also "freezes" the running application's memory allocation so nothing can be added."
19-07-2015, 14:40 door Anoniem
Tja,maar dan krijg je net als vroeger wel eens het geval was met andere software compatabliteitsproblemen.
Dat komt doordat de dll bibliotkeek wordt overschreven met een ander soort,dan van Microsoft zelf.
Dan krijg je met Windows een rommeltje.
Maar gelukkig is Windows zoveel beter geworden dat dt probleem zich niet meer voordoet.
Met WindowsXP gebeurde dan voorheen altijd,de dll problemen.
19-07-2015, 16:17 door karma4
Ik krijg er ook een raar gevoel bij.
- Monolytische programma's met statisch gelinkte modules hebben het nadeel dat universele routines niet geupdated worden zodra daar wat wijzigt . Oplossing: Dynamisch Linken
- Dynamisch linken deelt bij voorkeur de DLL code in het geheugen (minimalistie resource gebruik) tussen meerdere processen. Dat houdt in dat zoiets high privileged in memory moet worden geplaatst. Dat er meer code meekomt is logisch (performance). Het zou allemaal goed geteste code moeten zijn die logisch bij elkaar hoort (inclusief foutafvang).
- Overschrijf je DLL's in het geheugen dan ben je high-privileged bezig. Dat is nu net wat je niet wilt, juist wil voorkomen.
Vind je het concept van DLL's niet juist (komt op elk OS voor) dan zou je de discussie van monolitische programma's weer moeten gaan voeren. Dat lijkt me prima voor al die software die maandelijks verandert. Dat is een andere aanpak die meer bij de bron van het probleem zit. Dan krijg je ook het oude nadeel weer terug.
19-07-2015, 18:11 door Anoniem
Dat doet mijn antivirus de hele tijd al,die bevriest gewoon de hele pc voor een paar minuten.En dan krijg ik meestal melding dat de security een poging tot indringing in de pc heeft voorkomen.Tja dat is natuurlijk ook een manier om malware/hacking te stoppen,alleen wel irritant dat ik heel even niks met de pc kan doen behalve hem uit zetten/vd stroom afhalen,meestal is dat niet nodig,want na een tijdje reageert de pc dan wel weer,maar toch..het blijft fucking irritant dat die pc even "bevriest"..
19-07-2015, 20:00 door Anoniem
Onderzoekers vinden vaak het wiel opnieuw uit. Uit onwetendheid en uit blinde focus op hun eigen 'uitvinding'. Zie hier hetzelfde. Het is niet nieuw, bestaat al twee decenia.
19-07-2015, 20:47 door Anoniem
Met andere woorden "Onderzoekers maken virus dat software kan bevriezen" d'oh!
20-07-2015, 00:33 door Eric-Jan H te D
[Verwijderd]
20-07-2015, 01:38 door Anoniem
Beste collega's,

Dit is bedoeld voor exploit development. Omdat als je ROP (return oriented programming ) gebruikt tijdens het schrijven van een exploit dat zoek je in dll die door een programma zijn geladen naar instructies die op bepaalde geheugen adres van een dll staat. Dit KAN dus er voor zorgen dat veel exploits niet kunnen werken. Met ROP is het nu mogelijk om veel beveiligings mechanismen te omzeilen zoals DEP/ASRL. Het zal waarschijnlijk de kans op exploitatie kleiner maken omdat er minder instructie's in het geheugen zijn om gebruik van te maken.

Groet,

Umit
20-07-2015, 09:07 door Anoniem
kan me vergissen, maar dat heet suspenden toch?
En volgens mij bestaat dat al langer....
20-07-2015, 09:53 door Anoniem
De beschrijving roept bij mij vraagtekens op. Waarom noemen ze DLL machineinstructies "code"? Dat is ongebruikelijk en een beetje verwarrend.

Applicaties laden DLL's (dynamisch) doorgaans niet zelf, dat doen ze via het OS. Via exports wordt bepaald welke functiecalls worden geladen.

Hoe wordt bepaald welke functies wel/niet worden gebruikt? Dat zou toch geen seconden hoeven te duren, de image geeft het al aan (je kunt het zelfs met het blote oog in een hex editor zien), ook als er met LoadLibrary wordt geladen kun je het achterhalen.

(bij elke functie hoort een adres in de DLL)
20-07-2015, 10:11 door potshot
de beste stuurlui staan weer aan wal hoor..als jullie betweters nu eens zelf iets gaan doen aan alle domheden ,fouten,beleid,en andere ergernissen waarvan iedereen schijnbaar zomaar weet wat er aan scheelt maar niemand werkelijk iets aan doet.
maar dat zal wel te ver gegrepen zijn.
niet reageren want ik lees de flames toch niet.
20-07-2015, 11:55 door dutchfish - Bijgewerkt: 20-07-2015, 11:57
'Flawed by design' is de juiste term voor generieke bibliotheken die dit soort oplossingen noodzakelijk maken. Een erfenis uit het verleden waarbij het dynamisch laden van lib's verward ging worden met modules, waarbij iedere 'application developer' natuurlijk zijn eigen winkeltje in ging inrichten.

Kijken we naar de laatste manieren van out-of-process afhandeling dan kan daar in COM+ nog véél méér leuks (lees: ellende) mee worden uitgehaald.

Het geeft te denken dat van een Adobe applicatie een groot deel inactief kan worden gemaakt, zonder dat de applicatie (schijnbaar) onjuist gaat werken.

Terug naar af zou ik zeggen. Het wordt hoog tijd dat developers weer schaars leren omspringen met resources. Maar tegenwoordig hangt zowat heel het windows OS vast aan .NET bibliotheken. Zie dat maar eens 'lean and mean' te houden.

Ik heb niets tegen libraries, maar wel tegen process escalations op basis van redundant of latente code.

Alles afwegend vindt ik het helemaal niet zo'n gek idee om codefreeze op non-autherized stukjes uit de library toe te passen. Een stuk genuanceerder dan UAC.

Gaan we het hier mee redden? Nee, ik denk het niet. Een complete overhaul van .NET framework is nodig.

Mijn 2 centen
21-07-2015, 01:32 door Anoniem
Door karma4: Ik krijg er ook een raar gevoel bij.
- Monolytische programma's met statisch gelinkte modules hebben het nadeel dat universele routines niet geupdated worden zodra daar wat wijzigt . Oplossing: Dynamisch Linken
- Dynamisch linken deelt bij voorkeur de DLL code in het geheugen (minimalistie resource gebruik) tussen meerdere processen. Dat houdt in dat zoiets high privileged in memory moet worden geplaatst. Dat er meer code meekomt is logisch (performance). Het zou allemaal goed geteste code moeten zijn die logisch bij elkaar hoort (inclusief foutafvang).
- Overschrijf je DLL's in het geheugen dan ben je high-privileged bezig. Dat is nu net wat je niet wilt, juist wil voorkomen.
Vind je het concept van DLL's niet juist (komt op elk OS voor) dan zou je de discussie van monolitische programma's weer moeten gaan voeren. Dat lijkt me prima voor al die software die maandelijks verandert. Dat is een andere aanpak die meer bij de bron van het probleem zit. Dan krijg je ook het oude nadeel weer terug.

De WinSxS is zo omvangrijk geworden omdat Microsoft de DLL-hell heeft opgelost door voor elke applicatie die bepaalde DLL's nodig een kopie daarvan in de folder van betreffende applicatie binnen WinSxS te plaatsen.

De DLL-hell is daarmee teniet gedaan op een quick and dirty manier. En eigelijk is het gehele idee wat de grondslag van de DLL's vormde daarmee teniet gedaan. Kun je inderdaad niet zo goed monolitische software bouwen met statisch gelinkte modules.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.