Onderzoekers "bevriezen" software om malware te stoppen
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.
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."
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.
- 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.
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
En volgens mij bestaat dat al langer....
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)
maar dat zal wel te ver gegrepen zijn.
niet reageren want ik lees de flames toch niet.
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
- 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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
