reasonsphysicalmemory

NonamemanuscriptNo.
(willbeinsertedbytheeditor)U-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindowsAndreiLut,as,·AdrianColes,a·SándorLukács·DanLut,as,Received:date/Accepted:dateAbstractWeproposeamethodtoprotectuser-processesagainstmalicioussoftwareattacksrunninganintrospectionandprotectiontool(U-HIPE)insideahypervisor.
Ourso-lutionisbasedonhardwarevirtualizationsupport,impos-ing"no-write"and/or"no-execution"restrictionsondiffer-entguestvirtualmachine's(VM)memorypages.
Protectedcomponentsincludeprocess'threadstacks,heapsandload-ablemodules.
Thiswaymostattemptstoexecutemaliciouscodeinaprocessaredetectedandblocked.
Weproposeamethodtodealwithswappablepages.
Weinjectpage-faultexceptionsintheguestVMwhentryingtoreadswapped-outpagesforintrospection.
Wealsointerceptallswap-inandswap-outeventstocorrectlymaintainprotectiononneededmemorypages.
Weimplementedatestingprototypeforpro-tectinguser-processesinseveralMicrosoftWindowsoperat-ingsystems.
Testsweperformedprovedtheeffectivenessofoursolutionagainstattackslikepolymorphic/packedviruses,Thisistheacceptedauthors'version.
Thenalpublicationisavailableathttp://link.
springer.
com/article/10.
1007%2Fs11416-015-0237-zAndreiLut,as,BitdefenderCluj-Napoca400107,CuzaVodastr.
,no.
1,RomaniaE-mail:vlutas@bitdefender.
comAdrianColes,aTechnicalUniversityofCluj-NapocaCluj-Napoca400027,Baritiustr.
,no.
26–28,RomaniaE-mail:adrian.
colesa@cs.
utcluj.
roSándorLukácsBitdefenderCluj-Napoca400107,CuzaVodastr.
,no.
1,RomaniaE-mail:slukacs@bitdefender.
comDanLut,as,BitdefenderCluj-Napoca400107,CuzaVodastr.
,no.
1,RomaniaE-mail:dlutas@bitdefender.
comhookinjectionandinjectedcodeexecution.
Theintroducedoverheadisacceptableformostapplications.
Keywordsvirtualization·hypervisor·user-process·protection·introspection·swapped-out·page-fault·injection1IntroductionThebelow-OSimplementation[5,9,17,38]ofsecuritysolu-tionswasalogicalconsequenceofthelarge-scaleadoptionofvirtualizationusedtorunmorevirtualmachines(VM)onthesamephysicalsystem.
Thesecuritytoolsinsuchcasesarebasedonthecontrolcapabilitiesofthevirtualizationsys-tem,usuallycalledhypervisororVMmonitor(VMM).
Themainadvantagesofthebelow-OSstrategyovertheinside-OSalternativeare:(1)increasedsecurity,resultedfromtheisolationofthesecuritytoolfromthepossiblemalwareintheVM,and(2)simplerandmoreefcientdeployabilityforalargenumberofVMs.
Ontheotherhand,becausethebelow-OSsecuritytoolsuseintrospection[12,21,23]ofthemonitoredVM'smem-ory,theyfacesomechallenges,amongwhichpossibleper-formancepenaltiesandthesemanticgap[5,8].
Theperformancewasgreatlyimprovedduetothelat-estadvancementinthehardwarevirtualizationsupport[16].
Therewerealsoproposednumeroussolutionstoreducethesemanticgap.
TheoverallpurposewastodoithavingnoknowledgeabouttheguestOS.
Still,theresultingsolutionscouldbedividedintwoclasses:(1)(moreorless)guestOS-dependent[8,10,22,13,24],and(2)totallyguestOS-independent[19,18,20,34].
TheOS-dependentsolutionsre-quireknowledgeabouttheinternaldatastructuresoftheguestOS,whicharegenerallyobtainedthroughreverseen-gineeringtechniques.
So,forthesakeofgeneralityanOS-independentsolutionisdesired.
Unfortunately,themeaning2AndreiLut,as,etal.
oftheVMcontentsbasedonlyonthevirtualhardwareinfor-mationisverylimitedandalsolacksprecision.
ThisiswhyonproductionsystemsapureOS-independentapproachisnotrealistic,ifapplicableatall.
Therefore,weadoptedacombinedstrategy:OS-dependentmethodwhenprecisionandperformancearerequired,andOS-independentone,otherwise.
Evenso,ourOS-dependentmethodisgenericenough,asitusesbasicdatastructuresex-istentinsomeparticularforminmostOSes(e.
g.
Windows,Linux),likethelistofprocesses/threads,allocatedheaps,loadedmodulesetc.
Themaincontributionsofourpaperare:1.
Protectionagainstintrusionattacksonuser-modepro-cesses.
Manyexistenthypervisor-conductedsecurityso-lutionsintrospectcertainguestOSdatastructurestoei-therprotectthemagainstkernelrootkitattacksordetectalreadyinjectedmaliciouscodeinsidethekernel[28,31].
Justfewofthem[20,24,34,15]focusalsoonuser-modeprocessprotection.
Notwithstanding,thereareat-tacksthattargetonlyuserprocesses,whichcannotbedetectedbyonlyprotectingtheOSkernel.
Forinstance,attacksusingapplicationexploitstogainaccessonuserprocessesthatmanipulateimportantuserdata(e.
g.
themailclient,theInternetbrowser)donotneedatallcon-trollingtheOSkerneltobeabletostealandmanipulateusersecretdata,likepasswords,personallyidentiableinformation(PII),emails,contactsetc.
Ourproposedso-lutionaimsprotectionagainstsuchtypesofattacks,ap-plyingintrospectionandprotectiononboththekernelandusermemoryspaces.
2.
Protectionagainstanextendedrangeofattacksonuser-modeprocesses.
Theexistentuser-modeprocesssecu-ritysolutionsarelimitedregardingtheattacktypestheycouldghtagainst.
Forinstance,[34]onlyprotectsagainststacksmashingattacks,[20]reportstheexistenceofrun-ningmaliciousprocessesoruser-processcode,butcan-notblockthecorrespondingattackswhentheystart,and[24]blocksanymaliciousexecution,butrequirestheusertospecifyandmaintainadatabasewithauthorizedcode.
Weproposeasolutionthatprotectsuser-modepro-cessesagainstanextendedrangeofattacks,likepoly-morphic/packedviruses,hookinjectionandinjectedcodeexecution.
Theprotecteduser-processcomponentsarethethreadstacks,heapsandtheloadablemodules.
3.
Agenerichardware-baseduser-modeattackpreventionmethod.
Oursecuritytool(U-HIPE)activelymonitorsuser-processes,preventingtheattackoccurrences.
Itisbasedonhardwarevirtualizationsupportcommonlypro-videdbyalargerangeofmodernprocessors,likeIntel,AMD,ARMCortex-A15.
4.
AnOS-independentmethodtodealwithswapped-outpages.
Oursecuritytooltransparentlymanageswappablepagesforpurposesofintrospectionandprotectionmain-tenance,independentofthefactthattheyareinmemoryorswappedout.
5.
DetaileddescriptionofanimplementationofatestingprototypeofU-HIPEinseveralMicrosoftWindowsop-eratingsystems.
Real-lifetestsweperformedprovedtheeffectivenessofoursolutionagainstattackslikepoly-morphic/packedviruses,hookinjectionandinjectedcodeexecution.
Section2comparesU-HIPEwithothersolutions.
Sec-tion3describestheenvironmentassumptionswemakeandthethreatsoursolutioncouldfacesuccessfully.
Section4presentstheIntelvirtualizationsupportweuse.
Section5presentstheuser-processprotectionstrategy.
Section6de-scribesthepage-faultinjectionmechanismusedtoaccessswapped-outmemorypages.
Section7detailstheimple-mentationofU-HIPEonaWindowsOS.
Section8analyzesthesecuritycapabilitiesofU-HIPE.
Section9illustratestheevaluationresults,andSection10concludesthepaper.
2RelatedWorkSomebelow-OSsecuritysolutionsrequireeitherchangestotheguestOSsourcecode,e.
gSymCalls[22],Overshadow[6],InkTag[15],orinstallingcustomdriversintheguestOS,e.
g.
SecVisor[31]andLares[27].
Evenifsuchastrat-egycouldleadtoabetterperformance,itiseithernotappli-cableforclosed-sourceOSes,ortoointrusive,beingeasilydetectablebymalwareandpotentiallyvulnerabletoattacks.
Wechosethenon-intrusivealternative,althoughitfacesthesemanticgapproblem.
DifferentbysystemslikeGeiger[19],Antfarm[18],Ly-cosid[20],Ether[7],Virtuoso[8]thattrytoreducethese-manticgapbyinferringguestOSsemanticinformationrely-ingonlyonvirtualizedhardware,weadoptedanOS-dependentsolution.
Evenifnotsogeneral,webasedourprotectionmethodongeneralenoughdatastructures(e.
g.
process/threadlist,loadedmodules,heaps)thatexistinmostOSes(e.
g.
WindowsandLinux)andcouldeasilybelocatedbyanin-trospectionengine,makingiteasilyportable.
Wefoundourapproachmoreappropriateforproductionsystems,whereperformanceandprecisionareimportantrequirements.
Yet,wealsouseOS-independenttechniquestodealwithswap-pablepages.
SomesolutionslikeNICKLE[28],SecVisor[31],Lares[27],RTKDSM[14]dealwithprotectionoftheguestOS'codeordatastructures,otherslikeVMST[11,10]andVir-tuoso[8]introspectguestOSstructures,butnonecoulddealwiththeuser-space.
Thisiscomplementarytoourwork.
Still,werelyonthekernelcodebeingprotected.
Besides,wealsousesimilartechniquesbutforprotectinguser-processstructuresofinterest.
U-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindows3Therearesomesecuritysolutionsthatexplicitlyaimpro-tectingtheuserprocesses.
Systemslike[39],Overshadow[6]andInkTag[15]protecttrusteduser-processesbyato-tallyuntrustedguestOS.
Theybasetheirmethodonencrypt-ingtheprotectedpagesoftheuser-processesandpresent-ingtheOSwiththeencryptedversionofthosepages,whilethetrustedapplicationwiththedecryptedversion.
Whileanappealingmethod,itmustcontrolthewaytheguestOSchangesthepagingstructuresofprotectedprocesses.
WeconsiderthistointerferetoomuchwiththeguestOS'in-ternalpolicy,leadingtounpredictableperformanceresults.
Patagonix[24]interceptsexecutionattemptstouncoveranyuser-spacepagecontainingcode.
Basedonexecutableleformatstheycheckthedetectedexecutablepagesagainstauser-deneddatabase,blockinganyattempttoexecuteunau-thorizedcode.
Eveniflessgeneral,oursolutioncouldper-formbetter,sincewedirectlyidentifyfromguestOSstruc-turestheuser-processpagesthatmustbeprotected.
Thiswaywecouldblockdirectlyanyexecutiononcertainpro-cessareaanddonotneedcheckingthecodeagainstadatabase,whichisdifculttomaintaininpractice.
In[34]hardwareperformancecountersareusedtomon-itorcertaintypesofinstructions.
Theyproposeamethodtoprotecttheuser/kernelstacksagainststacksmashingat-tacks.
Contrary,weprotectotherprocessareas,aswell.
Be-sides,theirmethodismoreorlessaboutmonitoringinstruc-tionsandcouldbedifculttoadaptfordifferentotherattacktypes.
Veryfew[21,25,22]ofthebelow-OSsystemsprotectingeithertheguestOSoruser-processestakeintoaccounttheproblemofswappablepages.
Systemsdealingexclusivelywiththekernelspaceconsiderittobenon-swappable,whichisnotalwaysthecase.
Obviously,user-processpagescouldbeoftenswapped-out.
Havingtointrospectthemcouldberequiredevenforkernelprotectionsystems.
OursolutiontothisproblemistotallyOS-independent,relyingonlyonthepagingstructuresandmechanismssupportedbytheIntelar-chitecture.
IntroVirt[21]issimilartooursysteminthewaytheydealwithuser-processintrospection.
Theydetectattacksrun-ningknown-vulnerabilitypredicatesinsidetheguestVM,takingadvantageoftheguestOSfunctionality,likeaddresstranslationsandaccesstoswapped-outpages.
Theyplacebreakpointsondifferentlow-levelguestOSfunctionstode-tectswapinandoutevents,likewedo.
Similartothewaywedealwithswappablepages,theirsolutionisOS-dependent,whileourisOS-independent.
3ThreatModelandAssumptionsWemakethefollowingassumptionsregardingthecharac-teristicsoftheenvironmentoursecuritytoolwillruninto,suchthattobeeffective:–Theprocessorsprovideshardwarevirtualizationsupport(e.
g.
IntelVT-x,AMD-V,ARMVirtualizationExten-sions)withthefollowingextensions:secondlayerad-dresstranslation(SLAT)(e.
g.
IntelEPT,AMDRVI),I/Omemorymanagementunit(IOMMU)(e.
g.
IntelVT-d,AMD-Vi,ARMSMMU)andtrustedexecution(e.
g.
In-telTXT,ARMTrustZoneTEE).
SLATisusedtopro-tectmemorypages.
IOMMUisneededforprotectionagainstDMAattacks[37],whichcan,otherwise,eas-ilybypassEPTprotection.
Trustedexecutionsupportisusedtomeasuretheintegrityofalaunchedsoftware.
–Thetrustedcomputingbase(TCB)isformedbythephys-icalhardware,thermware,thehypervisorandourse-curitytool.
–Thebootingprocess(rmware,hypervisorloader,hy-pervisoritself,andoursecuritytool)ismeasuredforin-tegrityusingthetrustedexecutiontechnology.
Thiswaywearesurethesecurityenvironmentwebuildistheau-thentictrustedone.
TheintegrityoftheprotectedVM'sOSkernelisalsomeasuredatthemomentitislaunched.
Thisisimportantforourmethod,sincewesupposewestartprotectinganuncompromisedguestOS.
–CertainguestOS'ssections(e.
g.
kernel'scode,kerneldriver'scode,criticalkernelanddriverdatastructures,systemcalldispatchtable)areprotectedbytechniqueslikethosedescribedin[31,28].
Oursolutionalsoappliessimilartechniquestoprotectthekerneldatastructuresandcodeituses.
Howeverthisisnotthetopicofthispapersowewillnotconcentrateonit.
Thethreatmodelweconsiderconsistsin:–Thehostmachinecanundergoasecureboot,checkingforintegrityofthehypervisor.
–DuringtheguestOSinitializationphase,kernelsecurityprotectioncouldbeactivated,withnoattackrisks.
–Duringtheruntime,theguestOScouldbeattackedbykernelexploits.
–Thesecurityattackswemustfaceare:(1)hookinser-tion,(2)returnorientedprogramming(ROP)basedonheaporastackoverowandexecutionofinjectedcode,(3)unpackedcodeexecution.
4IntelVirtualizationSupport4.
1GeneralOverviewIntelVT-x[16]enablesahypervisortofullyemulatetheun-derlyinghardwareforoneormoreguestVMs.
Thehypervi-sorrunsinanewmoreprivilegedVMXrootoperationmode,whiletheguestcoderunsinalessprivilegedVMXnon-rootoperationmode.
VMcontrolstructure(VMCS)eldsallowthehypervisortoenableVMexits,i.
e.
trapsoftheCPUfromguesttohost(hypervisor),tobetriggeredoncertainevents4AndreiLut,as,etal.
happeningintheVM,likeexecutionofaprivilegedinstruc-tion.
AfterhandlingtheVMexit,thehypervisorpassesthecontrolbacktotheVMbydoingaVMentry.
4.
2MemoryVirtualizationTheExtendedPageTables(EPT)mechanismwasaddedtoassistthememoryvirtualization.
TheEPTisconguredbythehypervisorandactsasasecondlayerofaddresstransla-tion.
Whenpagingisactivatedinanon-virtualizedenviron-ment,theMemoryManagementUnit(MMU)usespagingstructurestotranslateavirtualaddresstoaphysicaladdress.
WhentheEPTareconguredbyanhypervisor,asec-ondtranslationphaseisadded.
IntherstphasetheCPUtranslatesaguestvirtualaddress(GVA)intoaguestphysi-caladdress(GPA),usingpagingstructuresinsidetheguestOS.
InthesecondphasetheCPUtranslatestheresultedGPAintoahostphysicaladdress(HPA),usingtheEPT.
TheEPTalsocontroltheaccessrightsonacertainGPA.
Threedifferentaccesstypescanbeconguredindividually:read,writeandexecuteaccess.
Ifanyoftheseisdenied,thecorrespondingtypeofaccessonthatpagewilltriggeraVMexitwiththereason"EPTviolation".
Thehypervisorwillhandlethisviolation:itmightemulateorsimplyskipthefaultinginstruction.
Thismechanismsitsattheheartofoursolutiontoprovidememoryprotectionthatisotherwiseverydifculttoachieve.
ThewayEPTareusedisillustratedinFigure1.
Detailsaboutprotectionsettingswillbegivenbelow.
4.
3EventInjectionSometimes,certaineventsneedtobeinjectedinsideoneguestVMfromthehypervisor,forvariousreasons.
Themostcommonaretheexternalinterrupts.
Injectionoffaults,trapsorexceptionsisalsosupported,allowingthehypervisortosimulateeventsthatdidnotactuallytakeplaceinsidetheVM.
Theeventinjectionmechanismallowsthedeliveryofaneventtogetherwithanerrorcode,ifnecessary.
TheeventwillbehandledbytheCPUwhenthecontrolispassedbacktotheguestOS.
Injectionofcertaineventsrequiresaddi-tionalsettings.
Forexample,incaseofapage-faultexcep-tioninjection,theCR2registermustcontaintheaddressthepage-faultwas"generated"on.
Thismechanismisalsocru-cialinourU-HIPE,sinceitallowsustoaccessswapped-outguestvirtualpages.
5User-ProcessProtectionMechanisms5.
1ChallengesWheneveranewprocessiscreated,U-HIPEshouldbeabletodecide,basedonuser-denedpolicies,whethertoactivateprotectiononitornot.
Itmustthenstartmonitoringthepro-cessforthreadstackscreation,heapscreationandmodulesloading,toactivateprotectiononthem.
Inordertodothat,U-HIPEmustbeabletointerceptthefollowingevents:1.
process/threadcreationandtermination;2.
heapcreationandtermination;3.
moduleloadingandunloading.
Correspondingly,itmustidentify,ineachcase,thememorypagesthatmustbeprotected.
Thereis,though,asignicantchallengeinachievingthisforuser-spacememory,becauseitisnormallypageable.
Thismeansthatatanygivenmoment,avirtualpageneededforintrospectionandprotectionmaybeswappedout,i.
e.
non-presentinmemory.
Thisposestwonewissues:1.
Howtoaccessapageifitisnotpresentinsidethephys-icalmemory2.
HowtoachieveprotectiononpagesthatarebeingswappedinandoutofthephysicalmemoryduetotheguestOSpagereplacementpolicy5.
2EventsInterceptionandMemoryProtectionEventdetectionisbasedonplacinghooksoncertainker-nelfunctionsorwrite-protectingcertainkerneloruser-spacestructures.
Functionhookingisnotthescopeofourpaper.
Itisdescribedinpaperslike[36]and[27].
ThemostimportanteventsU-HIPEmustinterceptareprocesscreationandtermination.
Theprotectionshouldbeactivatedbeforetheprocessisvisibleandattackablebyma-liciousprocesses.
Whenaprocessterminates,U-HIPEmustcleanlyremoveitsprotection.
Theseactionscoulddonebyeither:(1)hookingthekernelfunctionsthatactivate/deacti-vateaprocess(wewillpresentinSection7suchfunctionsforWindowsOS),or(2)interceptingmemoryeventsthatarespecictotheprocesscreation,suchaschangestotheguestOS'processlist.
Thelatertechniquecouldbedoneactivating"read-only"hardwareprotectiononthecorrespondingpages.
Wheneveranewnodewillbeaddedoranoldnoderemoved,writeswilltakeplaceinsidethislist,andthecorrespondingmem-oryviolationwillindicateU-HIPEthatanewprocesshasbeencreatedoraprocesshasbeenterminated.
Similartechniquesareusedtointerceptthreadcreationandterminationforaprotectedprocess.
Atthreadcreation,itsuser-modestackmustbeidentied,usuallyusingkernelU-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindows5Fig.
1:EPTprotectionsettingsfordifferentpagesintheuserprocess.
Codepagesrefertobothstaticallyloadedcodeanddynamicallyloadedlibraries.
Itcouldbenotedthatthecodepagesarerestrictedforbeingchanged(i.
e.
"no-write"protection),whileotherpagesarerestrictedforexecution(i.
e.
"no-execution"protection)oruserspecicdatastructures.
ThetypeofprotectionU-HIPEplacesonthestackpagesis"no-execution".
Whenathreadterminates,theprotectionofitsstackisremoved.
Insidetheuserrealm,weneedtointerceptheapcreationandterminationandusermodemodulesloadingandunload-ing.
U-HIPEinterceptstheseeventsbyplacing"read-only"protectiononthestructuresdescribingtheprocess:thelistofloadedmodulesandthelistofheaps.
Ifnecessary,intercep-tionofotherevents,suchasuser-modelibraryAPIs,couldalsobedone.
Alloftheseeventswilleventuallybeusedinordertoactivate:(1)"no-execution"protectiononthenewlycreatedheaps,and(2)"no-write"protectiononthenewlyloadedsharedlibraries.
TheEPTprotectiononthedifferentpagetypesisillus-tratedinFigure1.
Inordertokeepthepictureclear,wedidnotgurethe"read-only"restrictionsontheEPTentriesthatmaptheVMpagescontainingtheprocess'pagetables(seebelowinrelationtothetechniqueweusetokeeppagepro-tectiononswappablepages).
Though,theyaresimilartotheillustratedEPTentriesandcouldbeeasilyimaginedtakingintoaccountthatpagetablesthemselvesarealsostoredinguestphysicalmemoryframes,whichneedtobemappedontothehostphysicalmemorythroughEPTentries.
5.
3MemoryProtectionMaintenanceInsideEPT,U-HIPEmanipulatesonlyGPAsandHPAs.
Al-though,protectionmustbeappliedonGVAs.
Therefore,ifU-HIPEmustprotectaguestvirtualpage,thatpage'sGVAmustbetranslatedtoitscorrespondingGPAusingtheguestOS'pagingstructures.
ThefoundGPAcanthenbeprotectedinitscorrespondingentryinEPT.
Someproblemscouldarisewhentheguestvirtualpage(atGVA)isswappable,becausetheguestphysicalpage(atGPA)itismappedoncouldbechangedduetotheswappingoperationsinguestOS.
Letusassumethefollowings:(1)U-HIPEmustprotectavirtualpage,whoseaddressisGVA;(2)GVAtranslatestoGPA,viatheguestOS'pagetables;(3)U-HIPEprotectsGPAusingtheEPT.
Wecouldhavethefollowingproblematicsituations:1.
Falseprotection.
TheguestOSswapsoutGVAandre-placesitwithGVA,whichismappednowonGPA.
Inthiscase,U-HIPEcouldstillprotectGPA,evenifthe6AndreiLut,as,etal.
targetvirtualpage'sGVAdoesnotpointtoitanymore.
Actually,theprotectedpagewouldbeinthenewcong-urationthearbitraryGVA.
2.
Lostprotection.
TheguestOSswapsoutGVAandmapsnothingelsetoGPA.
Later,itswapsbackinGVA,butmapsittoGPA.
Inthiscase,U-HIPEcouldlosetheprotectiononGVA,sinceitcouldstillprotectGPAin-steadofGPA.
3.
Wrongprotection.
TheguestOSremapsGVAfromGPAtoGPA,withoutactuallyswappingthevirtualpage.
Thiscaseisasortofacombinationoftheprevioustwoones:aslongasGPAisnotallocatedtoanotherGVA,U-HIPEwouldsufferbylostprotection,whereasaslongastheGPAwouldbeallocatedtoanotherGVA,U-HIPEwouldalsosufferbyfalseprotection.
Figure2illustratesthethreecasesofprotectionprob-lemsmentionedabove:Figure2aillustratesthenormalpro-tectionmechanism,Figure2bthelostprotectionsituation,andFigure2cbothlostandwrongprotection.
Inordertoavoidsuchproblems,U-HIPEappliesEPT"no-write"protectionontheguestOS'spagingstructuresthemselves.
Thisway,everytimeacertainguestvirtualpageisbeingswappedinoroutanditscorrespondingpage-tableentry(PTE)mustbechanged,EPTviolationswillbetrig-gered,whichU-HIPEinterceptsandhandlestoadaptitsprotectioncorrespondingly.
Itdecodesthefaultyinstruction,extractsthenewvalueofthePTEthatistriedtobewrittenandcomparesitwiththecurrent(old)value,toinferifthecorrespondingpageis:1.
swapped-in:thepresentbithasatransitionfrom0to1;2.
swapped-out:thepresentbithasatransitionfrom1to0;3.
remapped:notransitionofthepresentbit,butachangeoftheGPA.
Othertimes,theguestOSmightonlytrymodifyingotherbitsinaPTE(e.
g.
read/writebitsorOSspecicbits).
Insuchcases,thecorrespondingwriteoperationwillbesimplyig-noredbyU-HIPE,sincethereisnopresentbittransitionandnoGPAchange.
Therearestillsomeotherproblemsthatmustbetakenintoaccount:1.
Non-presentpagetables.
TheguestOSpagetablecon-tainingthePTEofaprotectedpagecouldbefreedandmadenon-presentitselfwheneverthereisnopagemappedusingit.
Insuchacase,U-HIPEmustplaceEPT"no-write"protectionontheupperlevelpagingstructure(pagedirectory,inIntelterminology).
Thismethodmustbeextendedtothefullhierarchyofthetranslationpagingstructures.
2.
SharedPages.
Thisisthecase,forinstance,ofsharedlibraries,whicharephysicallyallocatedonetime,butmappedinsidethevirtualaddressspaceofeverypro-cessusingthem.
Whensuchlibrariescontainwritablepages,thosepagesaredealtwithbytheguestOSusingthe"copy-on-write"strategy.
Everywriteona"copy-on-write"page,triggersapage-faultexceptioninsidetheguestOS,lettingitallocateaprivatecopyofthatpageforthewritingprocessandchangecorrespondinglytheprocess'pagetable.
Basedonthe"no-write"protec-tionplacedontheguestOSpagetables,U-HIPEinter-ceptschangesimpliedbythecopy-on-writemechanismandtransparentlyadaptsitsprotectionlikeinthepageremappedcasedescribedabove.
5.
4Multi-CoreSupportWealsoconsideredthecasesofSymmetricMulti-Processor(SMP)systems.
Actually,theonlythingthatisinuencedbyrunningoursecuritycomponentonsuchasystemisthewaytheEPTstructuresaremanaged.
Therearetwostrategies:–centralizedEPT:thereisasinglesetofEPT,whicharesharedamongallVMCSsassignedtothevirtualCPUsgiventoaVM.
Thisway,protectionsettingsarecon-sistentamongallvirtualCPUs.
Though,inorderthismethodtobeeffective,concurrentchangesontheEPTentriescomingfromthemultipleCPUsmustbesyn-chronized.
Thiscouldbeeasilydoneinpracticeusingasortofspin-lock.
–distributedEPT:thereisadifferentsetofEPTforeachdifferentVMCS(implicitly,foreachvirtualCPU).
ThedifcultywiththismethodisthatallEPTsmustconsis-tentlyreectthesamememorycontentsandpagepro-tectionsettings,whichalsorequiresasortofsynchro-nizationbetweenthevirtualCPUs.
Wedecidedforthecentralizedstrategy,whileitissim-plertoimplementandalsobenetsfrommemorysaving.
AsortofCPUsconsistencymaintenanceisstillneededinthiscase,too.
ThisisbecauseeachCPUhasitsownTLBs.
WhenprotectionsettingsinsideanEPTentryarechangedbyoneprocessor,itinvalidatesitscorrespondingTLBentry.
Thatprocessorsends(afterapplyingthechanges)theotherprocessorsanIPI(i.
e.
inter-processorinterrupt)messagetoalsomakethemawareofthechanges.
Inresponse,theyin-validatethecorrespondingentriesintheirownTLBs.
Suchinvalidationcouldbemade,forinstance,onx86architecturebyusingtheINVEPTCPUinstruction.
6IntrospectionofSwapped-OutUser-ProcessPagesWesawinSection5thatU-HIPEneedstointrospectandprotectpagesinsideboththeguestkernelanduserspaces.
Therewouldbe,though,aproblem,ifU-HIPEtriestointro-spectaswapped-outpage.
U-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindows7(a)Thestateofentriesinprocesspagetables(controlledbytheguestOS)andEPT(controlledbythehypervisor)toprotectacertainvirtualpageattheGVAguestvirtualaddress.
TheprotectedGVApageisloaded(present)inthephysicalmemory.
(b)FalseprotectionduetowronglykeepingprotectionsettingsintheEPTentry,evenifthecorrespondingguest/hostphysicalmemoryframewasloadedwiththecontentsofanotherprocessvirtualpage,duetothepagereplacementpolicyintheguestOS,i.
e.
theprotectedGVApagewasswappedout,whileanunprotectedGVA*pagewasswappedin.
(c)Lostprotectionhappenswhenaprotectedprocessvirtualpageisswappedoutfromaphysicalmemoryframeandthenswappedbackinanotherframe,duetopagereplacementpoliciesinguestOS,yettheEPTentrykeepsprotectionontherstframe.
Wrongprotectionislikefalseprotection,butnothavingtheprotectedvirtualpagebeingswappedoutandin,onlymoved(andconsequently,remapped)inthephysicalmemory.
Fig.
2:Pageprotectionanomalies8AndreiLut,as,etal.
Thesolutionweproposeistoleveragetheexistentpage-fault(PF)handlingmechanismoftheguestOS.
AnytimeU-HIPEneedsaccessingaswapped-outguestpage,itwillin-jectapage-faultintheguestVM.
Thisway,U-HIPEmakestheguestOSthinksthatsomeprocessinsidetheguestVMtriedaccessingaswapped-outpage,andswapsitbackintothephysicalmemory,usingthenormalinternalswappingmechanism.
6.
1Page-FaultExceptionThePFexceptionisahardwareexceptiontriggeredwhen-evertheMMUcannotaccessavirtualaddress.
APFisgen-eratedwhen:aninstructionaccessesanon-presentpage,anuser-spaceinstructionaccesseskernelmemoryorwritein-sidearead-onlypage,CPUtriestofetchinstructionsfromanon-executablepage,etc.
OShandlestheexception,decid-ingwhattodo.
Ifthepagewasswapped-out,itwillswapitbackinmemory.
6.
2Page-FaultInjectionandHandlingWhenapage-fault(PF)isgenerated,theCPUcommuni-catestheOSthereasonforthepage-faultandthefaultyad-dress.
ThisinformationisprovidedonIntelprocessorsviathepage-faulterrorcode(PFEC)forthefaultreasonandtheCR2registerforthefaultyaddress.
U-HIPEloadsthecor-respondingeldsintheVMCSwithexpectedvalues(e.
g.
CR2withtheGVAoftheneededswapped-outpage),wheninjectingaPF.
WenotedthatmostOSesdonotcheckthefaultyinstruc-tion.
Becauseofthis,wedonothavetoworryatallabouttheinstructiontheIPregisterpointstowhenweinjectthepage-fault.
ThenextthingU-HIPEneedstosolveistodeterminethemomenttheswapped-outpageisbackinmemory.
Forthis,itmustinterceptthecorrespondingswap-inevent.
Thewaytodothisisbasedonprotectingfor"no-write"theguestOSpagetableandwasdescribedinSubsection5.
3.
PFinjectioncouldalsofacethesituationwhenapagetableitselfisnotpresentinmemory.
Insuchacase,inter-ceptingtheneededswap-ineventfunctionsintwosteps:in-terceptstheswap-inofthepagetablecontainingthePTEoftheneededpage,thenintercepttheswap-inofthepageitself.
Thismulti-stepinterceptionisbasedon"no-write"protectionofthehigher-levelpagingstructuresandwasalsodescribedinSubsection5.
3.
Whenthewaitedswap-ineventisintercepted,U-HIPEcanreadtheneededpagefromtheGPAitwillbemapped.
WhenthisactuallyhappensdependsontheOSanditssched-uler.
Usually,theinjectedPFisprocessedimmediately,butifaclockorinter-processorinterruptisdeliveredtothehan-dlingCPU,theactualprocessingofthePFwillbepost-poned.
AnotheraspectU-HIPEmustdealwithisthePFinjec-tionmoment.
Forauser-spacepage,aPFshouldnormallybeinjectedwhentheIPregisterpointsinsideauser-spacecodesegment.
Formostuser-spacepagesU-HIPEmustprotect,itinterceptsuser-modeevents(e.
g.
heapcreation,moduleloading),whentheIPisinuser-space,sotheinjectioncouldbedoneimmediately.
Otherinterceptedevents(e.
g.
threadcreation)correspond,however,tokernel-mode.
InthiscaseU-HIPEprotectsthePTEoftheneededswapped-outpageandpostponesthePFinjectionuntilthenextuser-modeeventinterception.
IfinthemeantimetheguestOSswapsintheneededpage,U-HIPEwillinterceptthecorrespondingswap-ineventandintrospectimmediatelythepage,needingnomoreaPFinjection.
APFinjectioncouldalsobeperformedwhentheIPpointsinsidetheguestkernel,foreitherakernelorauserpage.
However,severalothervalidationstoavoidpossibleraceconditionsmightbeneeded.
TheyarethoughveryOS-dependentandwedonotdealwiththemhere.
7U-HIPEImplementationonWindowsWeimplementedandtestedaprototypeofU-HIPEondif-ferentMSWindowsOSesforbothx86andx64proces-sors,startingwithWindowsVistaanduptothelatestWin-dows8.
1.
Certaininformationis,however,versiondepen-dent,suchasvariousoffsetsinsidethekerneldatastructuresweused,mainlybecausethesestructuresareopaqueandnotofciallydocumented.
Therefore,thecurrentdescriptionoftheimplementationwillbestronglydependentonthistypeofOS.
ThestepsdescribedinSection5willbedetailedinthissectionspecictoWindowsOSes.
Anotherimportantaspectthatmustbementionedisthefactthatwhileweaccessuser-modememory,weneverdoanyassumptionwithregardtotheaccessedmemory:iftherequiredmemoryispresent,wewillsimplyaccessit,butifitisnot,wewillusethemechanismsdescribedinSection6inordertoaccessswapped-outmemory.
Althoughmostofthetimesallthesestructureswillbemappedinsidethephysicalmemory,sometimes,especiallywhenthememorypressureishigh,thesestructuresmaybeswappedoutofthephysicalmemory.
7.
1InterceptingProcessCreationandTerminationProcesscreationisinterceptedusingtheinternalkernelfunc-tionPspInsertProcess()[30],whichbasicallyinsertsanewlycreatedprocessinsidethesystem'processlist.
Pro-cessterminationisinterceptedusingtheinternalkernelfunc-U-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindows9tionPspCleanupProcessAddressSpace().
Bothfunctionsareidentiedusingbinarypatternsmatchingonthefunc-tions'contents(signature).
Anothermethodwouldbetowrite-protectpagescon-tainingnodesofthelistofallcurrentlyactiveprocesses,pointedtobyPsActiveProcessHead.
Byinterceptingallwriteoperationsperformedonthislist,U-HIPEbasicallyinterceptsprocesscreationandterminationevents.
ThemaindrawbackoftherstmethodisthefactthatfunctionsignaturesmustbeextractedforeachsupportedOS,andthemaindrawbackofthesecondmethodisthesig-nicantperformanceimpact,sincethevirtualmemorypagesthatcontainthelistnodescouldcontainvariousotherstruc-turesthatmaybewrittenveryoften.
Themainadvantageoftherstmethodisitsperformance,whilethemainadvan-tageofthesecondoneisitssimplicity.
Inourimplementation,weoptedfortherstapproach,whichoffersthebestperformance.
ThestructurethatisusedbyU-HIPEistheEPROCESSstructure.
Thisstructuredescribestheprocessatthekernellevel.
Insidethisstructureweaccesstwoimportantelds:theDirectoryTableBaseeldinsidethePcbsub-eldoftheEPROCESSstructure,whichisthePDBR(PageDirectoryBaseRegister,i.
e.
CR3)ofthenewlycreatedprocess,andthePebeld,whichwillpointtotheuser-modePEB(Pro-cessEnvironmentBlock)structurethatidentiestheuser-modepartoftheprocess.
Iftheprocessisa32-bitprocessstartedonax64versionofwindows,aneweldwillbeused:Wow64Process,whichcontainsapointertothePEBstructurethatidentiesthe32-bitsubsystemofthenewlycreatedprocess,whiletheinitialPebeldcontainsapointertothe64-bitPEBoftheprocess.
7.
2InterceptingThreadCreationandTerminationAfteraprotectedprocesswasstartedandtheinitialprotec-tionactivatedonit,threadcreationisintercepted.
U-HIPEinterceptsthefunctionPspInsertThread()thatinsertsanewlycreatedthreadinsidethelistofactivethreads,func-tionPspExitThread()forthecaseathreadterminatesit-self,andfunctionPspTerminateThreadByPointer()forthecaseathreadisterminatedforcefullybyanotherthread.
Alternatively,wecouldintercepttheThreadListHeadeldinsidetheEPROCESSstructureoftheassociatedprocess,whichcontainsthelistofalltheprocess'threads.
Thead-vantagesanddisadvantagesofthesemethodsareidenticalwiththeonesdescribedfortheprocesscreationandtermi-nationinterception.
TheusedstructurewastheETHREADstructure,whichde-scribesathread.
ThemostimportanteldusedfromthisstructureisTebinsidetheTcbsubeldoftheETHREADstruc-ture,whichpointsinsideuser-modetoaTIB(ThreadInfor-mationBlock)structure,whichcontainsthebaseaddressofthethreadsstack:thisbaseaddresswillbeusedinordertoactivatestack"no-execution"protection.
Onceathreadhasterminated,theprotectionontheunderlyingstackwillberemoved.
7.
3InterceptingHeapCreationandTerminationInsidetheTEBstructure,theeldProcessHeapspointstoanarraycontainingtheaddressesofeachprocessheap.
FieldMaximumNumberOfHeapsidentiesthemaximumnumberofheapsthatcanbestoredinsidetheProcessHeapsar-rayandNumberOfHeapsthecurrentnumberofheaps.
AwriteinterceptioninsidetheProcessHeapsenablesustoidentifyheapcreationandtermination.
Whenaheapiscre-ated,"no-execution"protectionwillbeactivatedonit.
Whenaheapisdestroyed,theprotectionwillbeterminated.
Thesizeoftheheapwillbedeterminedfromtheheapdescrip-toritself.
Inordertodetectwhentheprocesshascreatedmorethanitsmaximumnumberofheaps,weintercepttheProcessHeapseldinsidethePEB.
WhentheOSwritesthiseld,wewillsimplymoveinterceptiononthenewar-ray,whichwillusuallybelargerthanthepreviousone.
Thisisbasicallya"realloc"operationfortheheapsarray.
7.
4InterceptingModulesLoadingInterceptionoflibrariesloadingisalsobasedonPEB.
FieldLdrpointstoa_PEB_LDR_DATAstructure,whichcontainsalinkedlistofuser-modelibrariesthatarecurrentlyloadedinsidetheprocess.
Inordertointerceptmoduleloading,U-HIPEprotectionas"no-write"theloadedmoduleslist.
Themechanismisidenticalwiththeinterceptionoftheprocessesorthreadslistsdescribedearlier.
Wheneveranewmoduleisloaded,itsassociatedstruc-tureLDR_MODULEisparsed.
Thisstructurecontainsalltheinformationaboutthegivenmodule:thepath,thebasead-dressandthesize.
Basedonthepath,U-HIPEdecideswhethertoactivatehookprotectiononthegivenmoduleornot.
Thehookprotectionwillapplytoeverynon-writablesectionofthemodule,includingtheImportAddressTable(IAT)andtheExportAddressTable(EAT).
Specialtreatmentispro-videdforthemainmodule,whichistherstmodulethatgetsloaded(beforeWindows8)orthesecondone,afterntdll(startingwithWindows8).
Itisprotectedagainstun-packingcode,inordertodetectpossibleinfectionswithle-infectors.
7.
5ImplementationandDebuggingDetailsBothU-HIPEandourhypervisorhavebeenwritteninC.
ThecodesizeofU-HIPEisroughly100KLOC,butalso10AndreiLut,as,etal.
includingfeaturesnotdescribedhereasbeingoutsidethescopeofthispaper.
Thedebuggingwasperformedusingtheserialport:thehypervisorwasdesignedtobothsendlogmessagesandac-ceptcontrolcommandsontheserialport.
Therefore,bothloggingfacilitiesandcommandinterpretationwereavail-ableinsidebothU-HIPEandthehypervisoratanymoment.
TheguestOShasbeendebuggedusingthenativeWindowsdebuggerWinDbg,viaaIEEE1394(Firewire)connection.
ThiswasneededinordertocheckandanalyzecertainguestOS'sstructuresandfunctionsusedbyU-HIPE.
ExamplesincludethehookedinternalfunctionsandtheinternalOSstructures,suchastheEPROCESS,ETHREAD,TEB,PEBandsoon.
7.
6AvoidingWindowsInternalProtectionItisknownthatthe64-biteditionsofMSWindowshaveaninternalkernelprotectionmechanismagainstkernelfunc-tionhooking.
TheprotectionmechanismiscalledKernelPatchProtection(KPP)orPatchGuard[30].
Normally,Patch-Guardwouldbeabletodetectthefactthatoursecurityso-lutionwouldhavechanged(i.
e.
hook)theaddressesofsomekernelfunctions,liketheonesforprocess/threadcreation.
Wedevelopedtwomethodstoavoidsuchaprotection:1.
ApplythehookingbeforethePatchGuardobservestheinitialkernelfunctionaddresses.
ThiswayPachGuardtakestheU-HIPE'shookedfunctionsastheoriginalWin-dows'ones.
Thedifcultyofthismethodisthewaytheappropriatehookingmomentisdetermined.
IntheWin-dowsversionsweimplementedU-HIPEfor,wefoundamomentduringthekernelinitializationbeforewhichPatchGuardisnotyetactive,particularlywhenMSRssuchasthesyscallMSRisbeinginitialized.
Theprob-lemofthissolutionisthatinfutureWindowsversionsPatchGuardmayinitializeearlierandthusrenderourmethoduseless.
2.
Applythehookingmechanismanytime,butrestricttheaccesstothepagescontainingthechangedfunctionad-dresses(e.
g.
congure"'no-read"accessinthecorre-spondingpagetableentriesinEPT),suchthatanyat-tempttoreadthehookedfunctionaddresseswilltriggeranaccessviolationexceptioninthehypervisor,givingitthepossibilitytoreturntheoriginalcontentastheresultofthereadoperations.
Otherwise,codeexecutioninsidethesepageswillbecarriedoutnormally,withoutfaults.
Themainadvantageofthersttechniqueisitsperfor-mance.
Ontheotherhand,itisnottotallytransparent,lettingthePatchGuardseeotherfunctionaddressesthantheorigi-nalones.
Onthecontrary,thesecondmethodprovidesper-fecttransparency,butatthecostofaperformancepenalty,whileeachreadaccesstothepagecontainingthefunctionaddresseswillgenerateanaccessviolationexception.
For-tunately,usuallyonlyPatchGuardreadsthesepagesanditdoessoonlyrarely(onceeveryseveralminutesorso),suchthattheperformancepenaltyisnotarealprobleminprac-tice.
Regardingtheothereventinterceptionmethodweused,i.
e.
settinginEPTwriterestrictionsonthepagescontain-ingdatastructuressupposedtobechangedinrelationtothemonitoredevents,itcouldnotbeevendetectedfrominsidetheguestOS,sotheinterceptionmechanismistotallytrans-parentforthePatchGuardinthiscase.
Actually,thistech-niqueisindependentontheguestOS,soithasnoparticu-laritiesforWindows.
8SecurityAnalysis8.
1SecurityPropertiesU-HIPEisimmunetodirectattacksfromtheguestVMduetoitsisolationimposedbythehardware.
Itsmemorycan-notbeaccessed,sincetheCPUforbidsthisduetotheSLATmechanism.
DMAattackscanalsobeavoidedifthehyper-visorusesanIOMMU.
U-HIPEcannotalsobedisabledormalfunctionedbymalware,sinceweassumedthatthebootprocessismeasuredusingtrustedexecutiontechnology.
Though,sinceU-HIPEdependsoninformationextractedfromtheguest,ifitwouldcontainvulnerabilities,itcouldbeexploitedbyanattackercapableofprovidingitspeciallycrafteddataabletotriggerthevulnerability.
However,duetoitssmallsizeandsimplicityitcouldtestedandveriedmoreeasierthananormalOS.
AnotherwayofattackingU-HIPEisthedenialofser-vice(DoS),butthiswouldbeoflittleusefortheattacker,sinceaDoSattackonU-HIPEwouldresultinaDoSontheguestOSitself,andthusrenderingthemalwareinert.
TheeventstheU-HIPEprotectionisbasedonwillal-waysbetriggeredcorrectly(e.
g.
anEPTviolation)becausetheattackercannotrecongurethehardwarememorypro-tectionimposedbyU-HIPE.
Thus,aslongasaprocessex-ists,allitsassociatedstructuresareprotected.
Theonlyap-parentlypossibleproblemwouldbeanattackonaprotectedprocess'memorystructures,launchedfromwithinacom-promisedguestOSkernel.
Sincethekernelisnormallymoreprivilegedthantheusermode,akernelrootkitcouldmali-ciouslychangeandmanipulatetheprocess'spagetablestobypasstheprocess'protection.
However,eventhistypeofattackislimited,sincetheprocess'pagetablesareprotectedandanypagetablechangeisinterceptedbyU-HIPE.
Thussimplyremappingorreallocatingprocess'memorywouldbeofnousefortheattacker,astheprotectionwouldsimplybemovedtothenewpages.
Regardingthepage-faultinjection,itcouldbeasecurityissueifanattackercouldsomehowgaincontroloftheguestU-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindows11OS'sPFhandlerfunctionality.
Thisway,theattackercouldprovideU-HIPEwithfakeGVAandfalseinformation,andthusavoidprotection.
However,aspreviouslymentionedinSection3,weassumethatthekernelcodeisalsosecured,soweconsidertheguest'sPFhandlertobetrusted.
8.
2PreventedAttacksPolymorphic/Packedviruses[33]infectingauser-processex-ecutesdecoding/unpackingcodethatwritessequencesofbytes,i.
e.
decrypted/unpackedcode,intoprocess'ownmem-oryandtriestoexecutethemlater,ananomalydescribedas"execute-after-write".
U-HIPEcouldblocksuchattacksbyapplying"no-execution"protectiononpreviouslywrit-tenpages.
Hookattacksinauser-processtrytoredirectfunctionsintheloadedlibrariesbychangingIAT/EATentriesorthefunctionstartingcode.
Eachprocesscontainsamain-module,whichistheac-tualapplication'scodethatgetsexecuted,andanumberofshareddynamiclibraries.
SomeoftheselibrariescontainOScode,includingAPIsthatwillgetcalledbythemainmod-ule.
Ifamalwaregetsaccesstoacertainprocess,itcanin-terferewiththenormalexecutionbyplacinghooksoncer-tainfunctionsinsidetheselibraries.
Typesofhookingin-cludefunction-tablehooking(modicationsinsideIATofacertainmoduleorinsidetheEAToftheattackedlibrary)andin-linefunctionhooking,thatinvolvesreplacingtherstfewbytesofafunctionwithabranchinstructiontoapieceofmaliciouscode.
Inbothcases,theintrospectionenginewillprotectas"no-write"(i.
e.
"read-only")thevirtualmem-orypagesthatcontaintheIAT,theEATandthecodeandwriteattemptsinsidethesepageswillbeforbidden.
Basi-cally,wheneversomeonetriestohookafunction(eitherviaIAT/EATorin-line),anEPTviolationwillbetriggered.
U-HIPEwillanalyzetheattempt,andifitdecidesitisma-licious,itwillblockitbyskippingthefaultinginstructionandthusblockinganymodicationtothecontentsoftheprotectedmemorypage.
U-HIPEcanalsoblockattacksthatexploitvulnerabili-ties(likebufferoverow)allowingmaliciouscodetobein-jectedandthenexecutedfromthestackorheapsofthevul-nerableprocess.
U-HIPEprotectionforthistypeofattacksisbasedonthe"no-execution"restrictionontheprocess'heapsandstacks.
Althoughtheheapsandthestacksofaprocess(alsothewrittencodepagesmentionedabove)shouldalsobeaggedbytheguestOSasbeing"non-executable",amaliciouspay-loadcaneasilybypassthisprotection[29]byremovingthe"non-execute"agonthesubsequentheaporstack.
Though,ifthe"no-execution"protectionisactivatedandcontrolledfromthehypervisor,itcannotberemoved,andtheattackscouldbeblocked.
Unfortunately,asitisknown,the"no-execution"protec-tioncannotghtagainstreturn-oriented-programming(ROP)attacks,whicharenotbasedonmalware-injectedcode,butonsmallcodesequencesfoundinstandardloadedsystemlibraries.
Suchattacks,whichdonotneedtheheaporthestackhostinganyinjectedcode,cannotbedetectedbyU-HIPE.
9TestsandResultsWeusedasystemwithIntelCorei7-2600CPUrunningat3400MHz,8logicalthreads(4coreswithHT)and16GBofDDR3,runningWindows7x64withSP1.
Testswereper-formedonbothrealandsyntheticuserapplications.
SametestswererunmoretimeswithandwithoutU-HIPEacti-vatedandtheaverageresultscalculated.
9.
1PerformanceTheperformanceimpactintroducedbyU-HIPEisgivenbyboththevirtualizationmechanismsitusesandtheactualprocessingitdoes.
9.
1.
1BenchingApplicationStartupTimeThestartuptimepenaltyforaprotectedprocessvarieswiththenumberofobjectsthatprocesscreatesduringitsini-tializationandcorrespondingly,U-HIPEneedstointrospectandprotect.
Aprocessthatcreatesmanyheapsandthreadswillstartslightlyslowerthananotheronecreatingnotasmany.
PassMarkAppTimer[32]wasusedtomeasurethepenaltyinducedbyU-HIPEondifferentapplicationsstartuptime.
Figure3andTable1illustratetheresultsforseveralap-plicationsrunwiththeirdefaultconguration.
Forsomeap-plications,e.
g.
Chrome,Opera,andInternetExplorer,theperformanceimpactishigher(startuptimeincreasedbyaboutanorderofmagnitude,comparedtothe"no-protection"case),becausetheyspawnotherprocesses,whichbeingalsopro-tectedbyU-HIPEincreasestheperformancepenalty.
Sim-pleprocesses,suchastheCalculator,haveamuchsmallerperformanceimpact,i.
e.
about22%.
WealsomeasuredtheinternalprocessingoverheadinducedbyU-HIPEtointro-spectandprotectuser-processstructuresforeachapplica-tion.
ThisisillustratedbythethirdbarinFigure3andlastcolumnofTable1.
Itismuchlowerthantheoverallover-headdetectedfromtheuserspaceinguestVM.
Thisisbe-causeU-HIPEwasimplementedinsideanexperimentalin-labhypervisor.
Weadmitthehypervisoroverheadisimpliedbyourprotectionneeds,stillweestimatethatfurtheropti-mizationsofthehypervisorwouldsignicantlydecreasetheoverallperformancepenalty.
12AndreiLut,as,etal.
ApplicationStartuptime(noprotection)[s]Startuptime(protection)[s]Introspectionpro-cessingtime[s]Overalloverhead[%]Introspectionoverhead[%]IE0.
01010.
495150.
027254802.
48269.
80Opera0.
07690.
439320.
01124471.
2814.
62Firefox0.
56041.
702750.
11489203.
8520.
50Chrome0.
125491.
447390.
092731053.
3973.
89AcrobatReader0.
072580.
523590.
05852621.
4080.
63MSOfce0.
032410.
038410.
0033118.
5110.
21Notepad0.
033470.
065180.
0046194.
7413.
77Calculator0.
053520.
065320.
0058922.
0511.
01Table1:Measurementsofdifferentapplications'startuptimeincasesprotectionwasactivatedornotFig.
3:Cumulatedoverheadoverthestart-uptimeofdiffer-entprocessesWealsonotedthattheperformanceoverheadincreaseslinearlywiththenumberofobjects(stacks,heaps,modules)U-HIPEmustprotectforaprocess.
Inrealapplicationsthenumberofsuchobjectsisaboutfewtensduringtheentirelifetimeofaprocessandwithjustfewofthembeingcre-ated/terminatedatonemoment.
Thustheoverallimpactisrelativelysmallerinpracticalcases.
Moreover,thisimpactismostlythestartuppenalty.
ThisisrevealedbyFigure4,whichillustratesanormalusageofacustomapplicationthatiteratedthroughallthelesofaharddisk,readtheirentirecontentsinmemoryandencryptedthem.
Thetestsrevealedanoverallimpactoflessthan4%.
9.
1.
2Page-FaultInjectionPenaltyThepage-faultinjectionusuallyhadaminimalimpactonthepagereplacementpolicyoftheguestOS.
Onaverage,weinjectedlessthantenforthepagescontainingtheneededdatastructures.
Page-faultinjectiontimingsvaryduetoOSthreadschedulinganddiskload.
Weran1000testsmeasur-ingthetimetookfromthemomentofthepage-faultinjec-tionandupuntilthemomentthepagewasswappedinandFig.
4:Cumulatedoverheadovertheentireruntimeofapro-cessU-HIPEwasnotied.
Wegotanaveragetimeofapproxi-mately0.
0149msforonesuchoperation.
Anotherfactorregardingtheperformanceoverheadin-troducedbyU-HIPEwouldbetheeffectofpage-faultin-jectionsontheTLBconguration,especiallyincaseswhenTLBwouldbefull.
Insuchasituation,injectingapage-faultwouldleadtoaTLBentryreplacement,justtomakeplaceforthemappingofthepagerequestedbyU-HIPE.
Evenifwedidnotperformedsuchspecictests(itwouldhavebeendifculttocreateandpreciselyevaluateinrealapplicationsthedescribedscenario),weconsiderthattheywerecoveredbythetestswedid.
Moreover,aswealreadymentioned,therewasaneedforonlyfewtensofpage-faultinjectionsduringtheentirelifetimeofanytestedprocess,whichsurelydidnothaveasignicantinuenceontheover-allperformance.
Ontheotherhand,therearesomeaspectsthatmakeourhypervisor-basedintrospectionperformevenbetterthatasimilartoolintegratedintheguestOS.
OnesuchaspectisrelatedtothewayTLBsareused.
Basically,therearetwotypesofTLBentriesmaintainedwhenEPTareused:oneforvirtualtophysicalguestmemorymappingsandoneforguesttohostphysicalmemorymappings.
Runningtheintro-U-HIPE:Hypervisor-BasedProtectionofUser-ModeProcessesinWindows13spectioncodeoutsidetheVMwillnotimposeextrapressureontheTLBentriesmappingguestaddresses,asitwouldanin-guestintrospection.
TheonlypossibleperformancepenaltywouldremainthatimpliedbytheU-HIPErequestsforadditionalswapped-outpages(i.
e.
injectedpage-faults).
Though,insuchcasestheperformancepenaltyincurredbytheTLBmissesisinpracticeirrelevant,comparedwiththatimpliedbythediskoperations(i.
e.
fewordersofmagnitudesmaller).
9.
2ProtectionU-HIPEwassuccessfullytestedagainstavarietyofmal-ware.
TestswithmaliciousapplicationswereperformedonafreshlyinstalledWindowsOSrunningonahostsystemthatwasdisconnectedfromthenetwork.
ThehypervisorandU-HIPEstartedbeforetheguestOS(eitherfromMBRorPXEboot)andactivateprotectionassoonastheOSstartstoini-tialize.
Themalwaresamplesweremanuallyrunonthetar-getsystemandalertsgeneratedbyU-HIPEwereobserved.
Examplesofmaliciousactionsattemptedbythetestedmalwareincludedexecutionofcodeinjectedonthestackorheapofacurrentlymonitoredprocessorinsideanotherprocesses,polymorphiccodeexecutionandhookinsertion.
ThesesamplescoverawideclassofattacksthatU-HIPEprevents.
Insomecases,actionsperformedbyrootkitswereclearlyblockedonthetargetsystem,aswasthecaseofBagle[26]orAgonythatwerepreventedtohidetheirinfectedpro-cessesand/orles.
Insomeothercases,liketheZBot/Zeustrojan[4],theprotectioneffectwasnotdirectlyvisiblebe-causetheattemptstoinjectcodeinsidetheprotectedpro-cesseshavebeencompletelyblocked.
Thestacksmashingattacksweresuccessfullydetectedandpreventedbyrunningtheexploitsforsomeknownvul-nerabilities[35]inMSOfceWord2007.
Thepolymorphiccodeandhookinsertiondetectorswerealsotestedsuccessfullyonvirusesthatnotonlyinfectatar-getprogram,butoncesuchatargetprogramgetsexecuted,theyalsoattempttohookcertainAPIsinsidethehostpro-cess.
Hookingpreventionwastestedondifferenttypesofhookingtechnique:(1)hooksplacedinsidesystemDLLs(usuallyuser32.
dll,ws2_32.
dllandwininet.
dll)asperformedbyleinfectorssuchasVirtob[3],Sality[2]andbymalwareintheZBotfamily,(2)hooksplacedinsidetheIRP/MJtableofthediskoratapidriverobject,performedbyTDLrootkit,and(3)in-linehooksplacedinsidesomekernelfunctionsorSSDT,asperformedbyBagleorAgony.
SimilartestswereperformedontheQhost[1]familyandvariousotherpasswordstealerandkey-loggerfamilies.
10ConclusionsWepresentedU-HIPE'sstrategyforprovidinguser-modeprocessesprotectionfrombelowtheguestOSanditsim-plementationonMSWindows.
Itsmaincontributionsare:(1)memoryprotectiontypesoncertainprocesscomponents;(2)maintenanceofmemoryprotectiononswappablepages;(3)page-faultinjectionmechanismtogetaccesstoswapped-outpages.
U-HIPEusesanOS-dependentintrospectionstrategy,yetthisisrealisticallyapplicableonproductionsystemsneed-ingprecision.
Theperformanceimpactisrelativelyhigh,es-peciallyonthestartuptime,comparedwiththeno-protectioncase.
Though,itisacceptableasacompromisebetweense-curityandperformancefornormaluserapplications(e.
g.
Internetbrowsers)usuallytargetedbymaliciousattacks.
Be-sidesanoptimizedhypervisorcouldsignicantlyreducethisimpact,aslongasinternalactionstakenbyU-HIPEdonotaccounttoomuchontheoveralluser-spaceperceivedover-head.
Ourmainfutureresearchinterestswillmainlyconcen-trateon:1.
Provingthesupportforotheroperatingsystemfamilies,suchasLinux;2.
ImprovingtheperformanceofU-HIPE,especiallyfornewprocessandthreadlaunchingoperation.
AcknowledgementsThesecondauthor'sworkonthispaperwassup-portedbythePost-DoctoralProgrammePOSDRU/159/1.
5/S/137516,projectco-fundedfromEuropeanSocialFundthroughtheHumanRe-sourcesSectorialOperationalProgram2007-2013.
ThenalpublicationisavailableatSpringerviahttp://link.
springer.
com/article/10.
1007%2Fs11416-015-0237-z.
References1.
Bitdefender:QhostVirusDescription2.
Bitdefender:SalityVirusDescription3.
Bitdefender:VirtobVirusDescription4.
Bitdefender:ZbotVirusDescription5.
Chen,P.
M.
,Noble,B.
D.
:WhenVirtualIsBetterThanReal.
In:ProceedingsoftheEighthWorkshoponHotTopicsinOperatingSystems,HOTOS'01.
IEEEComputerSociety,Washington,DC,USA(2001)6.
Chen,X.
,Garnkel,T.
,Lewis,E.
C.
,Subrahmanyam,P.
,Wald-spurger,C.
A.
,Boneh,D.
,Dwoskin,J.
,Ports,D.
R.
K.
:Over-shadow:avirtualization-basedapproachtoretrottingprotectionincommodityoperatingsystems.
SIGOPSOper.
Syst.
Rev.
42(2),2–13(2008).
DOI10.
1145/1353535.
13462847.
Dinaburg,A.
,Royal,P.
,Sharif,M.
,Lee,W.
:Ether:MalwareAnal-ysisViaHardwareVirtualizationExtensions.
In:Proceedingsofthe15thACMconferenceonComputerandcommunicationsse-curity,CCS'08,pp.
51–62.
ACM,NewYork,NY,USA(2008).
DOI10.
1145/1455770.
14557798.
Dolan-Gavitt,B.
,Leek,T.
,Zhivich,M.
,Gifn,J.
,Lee,W.
:Virtu-oso:NarrowingtheSemanticGapinVirtualMachineIntrospec-tion.
In:IEEESymposiumonSecurityandPrivacy(SP),pp.
297–312.
IEEE.
DOI10.
1109/sp.
2011.
1114AndreiLut,as,etal.
9.
Dunlap,G.
W.
,King,S.
T.
,Cinar,S.
,Basrai,M.
A.
,Chen,P.
M.
:ReVirt:enablingintrusionanalysisthroughvirtual-machinelog-gingandreplay.
SIGOPSOper.
Syst.
Rev.
(SI),211–224.
DOI10.
1145/844128.
84414810.
Fu,Y.
,Lin,Z.
:BridgingtheSemanticGapinVirtualMachineIntrospectionviaOnlineKernelDataRedirection.
ACMTrans.
Inf.
Syst.
Secur.
(2).
DOI10.
1145/250512411.
Fu,Y.
,Lin,Z.
:SpaceTravelingAcrossVM:AutomaticallyBridg-ingtheSemanticGapinVirtualMachineIntrospectionviaOnlineKernelDataRedirection.
In:Proceedingsofthe2012IEEESym-posiumonSecurityandPrivacy,SP'12,pp.
586–600.
IEEECom-puterSociety,Washington,DC,USA.
DOI10.
1109/sp.
2012.
4012.
Garnkel,T.
,Rosenblum,M.
:AVirtualMachineIntrospectionBasedArchitectureforIntrusionDetection.
In:InProc.
Net-workandDistributedSystemsSecuritySymposium,pp.
191–206(2003)13.
Gavitt,B.
D.
,Leek,T.
,Hodosh,J.
,Lee,W.
:TappanZee(North)Bridge:MiningMemoryAccessesforIntrospection.
In:Pro-ceedingsofthe2013ACMSIGSACConferenceonComputerandCommunicationSecurity,CCS'13,pp.
839–850.
ACM,NewYork,NY,USA.
DOI10.
1145/2508859.
251669714.
Hizver,J.
,Chiueh,T.
c.
:Real-timedeepvirtualmachineintro-spectionanditsapplications.
In:Proceedingsofthe10thACMSIGPLAN/SIGOPSInternationalConferenceonVirtualExecu-tionEnvironments,VEE'14,pp.
3–14(2014)15.
Hofmann,O.
S.
,Kim,S.
,Dunn,A.
M.
,Lee,M.
Z.
,Witchel,E.
:Ink-Tag:SecureApplicationsonanUntrustedOperatingSystem.
SIG-PLANNot.
(4),265–278.
DOI10.
1145/2499368.
245114616.
IntelCorporation:IntelR64andIA-32ArchitecturesSoftwareDeveloper'sManual(2015)17.
Jiang,X.
,Wang,X.
,Xu,D.
:StealthyMalwareDetectionandMonitoringThroughVMM-based"Out-of-the-box"SemanticViewReconstruction.
ACMTrans.
Inf.
Syst.
Secur.
(2).
DOI10.
1145/1698750.
169875218.
Jones,S.
T.
,ArpaciDusseau,A.
C.
,ArpaciDusseau,R.
H.
:Ant-farm:trackingprocessesinavirtualmachineenvironment.
In:ProceedingsoftheannualconferenceonUSENIX'06AnnualTechnicalConference,ATEC'06,pp.
1–14.
USENIXAssoci-ation,Berkeley,CA,USA19.
Jones,S.
T.
,ArpaciDusseau,A.
C.
,ArpaciDusseau,R.
H.
:Geiger:Monitoringthebuffercacheinavirtualmachineenvironment.
SIGARCHComput.
Archit.
News(5),14–24.
DOI10.
1145/1168919.
116886120.
Jones,S.
T.
,ArpaciDusseau,A.
C.
,ArpaciDusseau,R.
H.
:VMM-basedhiddenprocessdetectionandidenticationusingLycosid.
In:ProceedingsofthefourthACMSIGPLAN/SIGOPSinterna-tionalconferenceonVirtualexecutionenvironments,VEE'08,pp.
91–100.
ACM,NewYork,NY,USA.
DOI10.
1145/1346256.
134626921.
Joshi,A.
,King,S.
T.
,Dunlap,G.
W.
,Chen,P.
M.
:DetectingPastandPresentIntrusionsThroughVulnerability-specicPredicates.
In:ProceedingsoftheTwentiethACMSymposiumonOperatingSystemsPrinciples,SOSP'05,pp.
91–104.
ACM,NewYork,NY,USA.
DOI10.
1145/1095810.
109582022.
Lange,J.
R.
,Dinda,P.
:SymCall:SymbioticvirtualizationthroughVMM-to-guestupcalls.
In:Proceedingsofthe7thACMSIG-PLAN/SIGOPSInternationalConferenceonVirtualExecutionEnvironments,VEE'11,pp.
193–204.
ACM,NewYork,NY,USA.
DOI10.
1145/1952682.
195270723.
Laureano,M.
,Maziero,C.
,Jamhour,E.
:IntrusionDetectioninVirtualMachineEnvironments.
In:Proceedingsofthe30thEUROMICROConference,EUROMICRO'04,pp.
520–525.
IEEEComputerSociety,Washington,DC,USA.
DOI10.
1109/euromicro.
2004.
4824.
Litty,L.
,Cavilla,A.
L.
,Lie,D.
:Hypervisorsupportforidentify-ingcovertlyexecutingbinaries.
In:Proceedingsofthe17thCon-ferenceonSecuritySymposium,SS'08,pp.
243–258.
USENIXAssociation,Berkeley,CA,USA25.
Martignoni,L.
,Fattori,A.
,Paleari,R.
,Cavallaro,L.
:Liveandtrustworthyforensicanalysisofcommodityproductionsystems.
In:Proceedingsofthe13thInternationalConferenceonRe-centAdvancesinIntrusionDetection,RAID'10,pp.
297–316.
Springer-Verlag,Berlin,Heidelberg26.
Microsoft:Win32/Bagle27.
Payne,B.
D.
,Carbone,M.
,Sharif,M.
,Lee,W.
:Lares:Anarchi-tectureforsecureactivemonitoringusingvirtualization.
In:Pro-ceedingsofthe2008IEEESymposiumonSecurityandPrivacy,SP'08,pp.
233–247.
IEEEComputerSociety,Washington,DC,USA.
DOI10.
1109/SP.
2008.
2428.
Riley,R.
,Jiang,X.
,Xu,D.
:Guest-TransparentPreventionofKer-nelRootkitswithVMM-BasedMemoryShadowing.
In:Proceed-ingsofthe11thInternationalSymposiumonRecentAdvancesinIntrusionDetection,RAID'08,pp.
1–20.
Springer-Verlag,Berlin,Heidelberg.
DOI10.
1007/978-3-540-87403-4\_129.
Roemer,R.
,Buchanan,E.
,Shacham,H.
,Savage,S.
:Return-Orientedprogramming:Systems,languages,andapplications.
ACMTrans.
Inf.
Syst.
Secur.
(1).
DOI10.
1145/2133375.
213337730.
Russinovich,M.
E.
,Solomon,D.
A.
,Ionescu,A.
:WindowsInter-nals,6thed.
edn.
MicrosoftPress(2012)31.
Seshadri,A.
,Luk,M.
,Qu,N.
,Perrig,A.
:SecVisor:atinyhypervi-sortoprovidelifetimekernelcodeintegrityforcommodityOSes.
In:Proceedingsoftwenty-rstACMSIGOPSsymposiumonOp-eratingsystemsprinciples,SOSP'07,vol.
41,pp.
335–350.
ACM(2007).
DOI10.
1145/1294261.
129429432.
Software,P.
:AppTimer.
ApplicationStartupTimer33.
Szor,P.
:TheArtofComputerVirusResearchandDefense.
Addison-WesleyProfessional34.
Vogl,S.
,Eckert,C.
:UsinghardwareperformanceeventsforInstruction-Levelmonitoringonthex86architecture.
In:Proceed-ingsofthe2012EuropeanWorkshoponSystemSecurity(Eu-roSec'12)35.
Vulnerabilities,C.
,Exposures:CVE-2010-333336.
Wang,Z.
,Jiang,X.
,Cui,W.
,Ning,P.
:Counteringkernelrootk-itswithlightweighthookprotection.
In:Proceedingsofthe16thACMconferenceonComputerandcommunicationssecurity,CCS'09,pp.
545–554.
ACM(2009).
DOI10.
1145/1653662.
165372837.
Wojtczuk,R.
,Rutkowska,J.
:FollowingtheWhiteRabbit:Soft-wareAttacksAgainstIntelVT-dTechnology38.
Yan,L.
K.
,Jayachandra,M.
,Zhang,M.
,Yin,H.
:V2E:combin-inghardwarevirtualizationandsoftwareemulationfortransparentandextensiblemalwareanalysis.
SIGPLANNot.
(7),227–238.
DOI10.
1145/2365864.
215105339.
Yang,J.
,Shin,K.
G.
:Usinghypervisortoprovidedatasecrecyforuserapplicationsonaper-pagebasis.
In:ProceedingsoftheFourthACMSIGPLAN/SIGOPSInternationalConferenceonVirtualExecutionEnvironments,VEE'08,pp.
71–80.
ACM,NewYork,NY,USA.
DOI10.
1145/1346256.
1346267