BaiduX-Lab
1
AdaptiveKernelLivePatching:AnOpenCollaborativeEfforttoAmeliorateAndroidN-dayRootExploits
YulongZhang,YueChen,ChenfuBao,LiangzhaoXia,LongriZhen,YongqiangLu,andTaoWei
BaiduX-Lab
1.Background
Androidkernelvulnerabilitiesaredangerous.AttackerscanexploitkernelvulnerabilitiestorootAndroiddevicesandachievemaliciousgoals.Ifthekernelgetscompromised,allsecuritymechanismsrelyingonkernelintegrity(e.g.appsandboxing,payment/fingerprintframework,etc.)willbebroken.TrustZone,thelastlineofdefenseforAndroiddevices,willalsobethreatenedasthecompromisedkernelenablestheattackertoinjectmaliciouspayloadsintoTrustZone.So,itisidealtogetridofkernelvulnerabilities.However,moreandmorekernelvulnerabilitieshavebeenunveiledeachmonth(showninFigure1).Ononehand,thisisagoodtrendindicatingmoreandmoreefforthasbeenspentonsecuringtheAndroidkernel;ontheotherhand,kernelvulnerabilitiesthathavebeendisclosedbutremainunfixedhavebecomethelargestthreatforAndroidusers.Havingbeeninthespotlightforweeksorevenmonths,theyusuallyhavepublicandstableexploits,andthusbecomeundergroundbusinesses’favorite.Forexample,fromtherecentpopularmalwareincidentswithglobalimpact[1-4],onecanalwaysfindaroottoolkitinside.SuchrootexploitsareeitherfrompublicProof-of-Concept(PoC),orcopiedfromone-clickrootapps.Consequencesofthesemalwareincludefrauds,credentialleakage,fingerprintleakage,losingmoneyfrombanking/payment/financialaccounts,orevenremotecontrols.
Figure1:NumberofkernelvulnerabilitiesdisclosedinmonthlyAndroidSecurityBulletin
1 1 3 4 4 715 19
66
2015/09 2015/12 2016/01 2016/02 2016/03 2016/04 2016/05 2016/06 2016/07
MonthlyDisclosedNumberofKernelVulnerabilities
BaiduX-Lab
2
Peoplecommonlyclaimthat“usingAndroidiseasiertobeattacked”,or“AndroidislesssecurethaniOS”.Actually,ifwesimplycomparethekernelvulnerabilitiesdisclosedineachiOSrelease(Table1),itappearsthatiOS’kernelvulnerabilitydisclosurefrequencyisnotlessthanAndroid’s.SotherootcauseoftheproblemisnotonlythatAndroidhasfrequentvulnerabilitydisclosures,butalsobecausethesevulnerabilitiesremainunfixedoveralongtime.
iOSVersion ReleaseDate KernelVulnerability# Android#InThisPeriod8.4.1 8/13/15 3 -9 9/16/15 12 19.1 10/21/15 6 -9.2 12/8/15 5 19.2.1 1/19/16 4 39.3 3/21/16 9 89.3.2 5/16/16 11 22
Table1:iOSkernelvulnerabilitiesdisclosedineachrelease,comparedtothatofAndroid.Notethatthenumberofvulnerabilitiesmaynotbedirectlycomparableduetodifferentthreatlevels.ButthecomparisoncanstillprovidearoughsensethatiOSisnot
bornas“bullet-proof”;itismoresecurejustbecauseitcangettimelypatchesinalargescale.
2.WhyAreAndroidKernelVulnerabilitiesLong-lasting?
WhyAndroidcannotgetthesekernelvulnerabilitiespatchedinatimelymannerlikeiOS?Therearemainlythreecauses:
1) Thelongpatchingchaindelaysthepatcheffectivedate;2) Fragmentationmakesitchallengingtoadaptthepatchestoalldevices;3) Capabilitymismatchingbetweendevicevendorsandsecurityvendors.
Thesecausesarediscussedindetailbelow.2.1TheLongPatchingChain
AsshowninFigure2,itusuallytakesmonthsorevenyearsforapatchtopassallstagesandlandonusers’phones,nottomentionthatsomepatchesmaybediscardedinoneofthesestages.Forexample,inanacademicstudy[5],theauthorsclaimthatfromreverse-engineeringafamousrootapp,theyfoundatleast10kernelexploitsthathaveneverbeenreportedtovendors.Inthiscase,thevulnerabilitieshavebeenidentifiedandmadepublic(sinceeveryonecanreverse-engineerthatfamousrootapptounderstandthevulnerabilities,orevenreusetherootexploitlibrarydirectly),butthevendorsdidnotknowtheirexistence,sothereisnopatchreleasedthroughtheofficialpatchingchanneltopatchthem.Thisistheschemewherethepatchingchainstopsattheveryfirststage.
BaiduX-Lab
3
Figure2:ThelongpatchingcircleofAndroidkernelvulnerabilities
Asanotherexample,GoogleProjectZeroidentifiedabug[6]butsomehowitwasnotappliedtovendor’skernelbranch.Soaccordingtothispost,“themajorityofAndroidkernelsbasedon3.4or3.10arestillaffecteddespitethepatchbeingavailablefor6months”.Thisistheschemewherethepatchingchaingotdelayedbeforereachingthethirdstage.Thefirstthreestepscouldbeskippedifthephonevendorsarewillingtoallocateenormousresourcesandmanpowertoidentifykernelvulnerabilitiesandreleasepatchestimely.However,thepatchingchainwouldstillbedelayedbythecarriers[7],whoneedtothoroughlytestwhetheraproposedpatchaffectsthestabilityandservicequalityofthecarrierphones.Finally,whenanOver-The-Air(OTA)patcharrivesatthedevices,usersmaynotbewillingtotakethepatchimmediatelysincemostofthecoldpatchesrequirephonerebootingtobecomeeffective.Sotheconcernofinterruptinguserexperiencefurtherdelaysthetraditionalpatches’effectivedate.2.2Fragmentation
TheAndroidecosystemisopen.Therearecountlessvendorsandeachvendorusuallyhasmanyphonemodels(Figure3).Thedifferentpatchingstatusofvariousmodelscausesfragmentation.Itistedioustomanuallyportapatchtosomanyplatforms,whichfurtherslowsdownthepatchingprocess.
Figure3:Androiddevicefragmentation,citedfrom[8]
BaiduX-Lab
4
GooglealsoprovidesofficialstatisticsoffragmentedAndroidversiondistribution[9].Thefollowingfactsstandout:
1) Lollipop(Android5.0)wasreleasedinNovember2014,butasofJuly21,2016,51.6%ofthedevicesarestillolderthanthat.ThisindicatesthatthewholeAndroidecosystemisslowtocatchupwiththelatestAndroidrelease.
2) GooglehasstoppedprovidingpatchesforAndroidolderthan4.4,butasofJuly21,2016,21.5%ofthedevicesarestillolderthanthat.Thismeansthatmorethan1/5ofthedeviceswillneverreceivetimelypatches.
Makingthesituationworse,theworld’slargestAndroidmarket,China,blocksnetworkaccesstoGoogle,soChinesedevicescannotobtainOTApatchesdirectlyfromGoogle.Duetothesamereason,ChinesedevicescannotreporttheirpatchingleveltoGoogle,thusGoogle’sAndroidversionstatisticsdonotincludeChinesedevices–iftheydo,thestatisticsshouldlookevenmoreupsetting.WerandomlycollectedtheAndroidversionsofnearlytwomillionsofdeviceswithBaiduappsinstalled,andobservedthefollowingfacts:
1) Lollipop(Android5.0)wasreleasedinNovember2014,butasofJuly21,2016,80%oftheChinesedevicesarestillolderthanthat.
2) GooglehasstoppedprovidingpatchesforAndroidolderthan4.4,butasofJuly21,2016,42%oftheChinesedevicesarestillolderthanthat.
Therefore,theproblemisnotonlytoadaptpatchestolotsofplatforms,butalsotoadaptpatchesforsomanyolddevices.Mostdevicevendorsfocusmoreonpromotingnewdevicesratherthanprovidingsupportfordevicesmorethan2yearsold.Soalthoughtherearestillaconsiderableamountofusersstickingtoolddevices,theywillunfortunatelynotreceivetimelypatches.2.3CapabilityMismatching
Devicevendorshaveprivilegeshighenoughtoapplythepatchesonthephone.Theycanalsoadaptthepatchesbasedonthesourcecodetheypossess–itistedious,butstillfeasible.Butasmentionedabove,theirfirstpriorityisnottopatchthedevicestobullet-proof.Moreover,exploitsanddefensesarenottheirareaofexpertise.Onthecontrary,othershaveinteresttoprovidetimelypatchesfordevices,likesecurityvendors(forfameandprofit)anddevelopersofappsrelyingonAndroidsecurity(forriskcontrol).Theyhavebetterunderstandingofthereal-worldthreatstoo.However,sincedevicevendorsusuallydon’tpublishtheexactup-to-datekernelsourcecodeforalldevices,itisextremelydifficultforthirdpartiestoadaptpatchesforalldevices.Itisalsochallengingforthirdpartiestoapplypatchessincetheydon’thaveenoughprivileges.Wecallthisdilemmaas“CapabilityMismatching”–thosecapabletoapplythepatchdonothavehighestinterestorexpertisetogeneratethepatch,whilethosecapabletogeneratethepatchdonothavecapabilitytoadaptandapplythepatches.ThisisthethirdbutstillanimportantcauseoftheAndroid’svulnerabilitiesremainingunfixedforalongtime.
BaiduX-Lab
5
Nowthatwehaveidentifiedthethreemajorcauses,wecanexplainwhyAndroidappearstobelesssecurethaniOS:
1) Applecontrolstheentiresupplychain,fromhardwaretosoftware,andhavemorerightsspeakingtocarriers,soitspatchingchainissignificantlyshorter.
2) ThenumberofiOSdevicevariantsismuchsmallerthanAndroid’s,andApplehasthesourcecodeforthem,soitismucheasierforAppletogenerateandadaptpatchesforallvariants.
3) Fromtimetotime,Applerefusestosignoldversions,sodevicescanonlybeupgradedanddowngradingisnotpossible.
3.CaseStudiesofLong-livedKernelVulnerabilities
Hereweusethreewidelyexploitedcross-platformkernelvulnerabilitiesforcasestudies.ThefirstoneisCVE-2014-3153,knownas“Towelroot”.Thevulnerabilityisduetothatthefutex_requeuefunctioninkernelthrough3.14.5doesnotensurethatcallshavetwodifferentfutexaddresses,whichallowslocaluserstogainprivileges.AtitstimebeingtherewasnoAndroidSecurityBulletinissued,soweconservativelycountthefirst-knowndateasthetimewhenthisvulnerabilitywasfirstlypatchedintheupstreamkernel:June3,2014[10].ThesecondoneisCVE-2015-3636,knownas“PingPongRoot”.Theping_unhashfunctioninkernelbefore4.0.3doesnotinitializeacertainlistdatastructureduringanunhashoperation,whichallowslocaluserstogainprivilegesorcauseadenialofservice.TheAndroidSecurityAdvisoryforthisvulnerabilitywaspublishedonSeptember9,2015[11].ThethirdoneisCVE-2015-1805,wherethepipe_readandpipe_writeimplementationsinkernelbefore3.16allowslocaluserstogainprivilegesviaacraftedapplication.TheupstreampatchingdateisApril3,2014[12].ThisvulnerabilityisveryinterestingbecauseitwasfixedinupstreambutwasnotassignedaCVEnumberuntilFebruary,2015.However,noAndroidpatchwasprovidedforthisvulnerabilityuntilearly2016whenresearchersnotifiedGooglethattheissuecouldbeexploitedandhadbeenabusedinthewild.TheAndroidSecurityAdvisoryforthisvulnerabilitywaspublishedonMarch18,2016[13].Figure4showstheelapseddaysfromtheadvisorypublicationdateforthethreerepresentativekernelvulnerabilities.Themoredayselapsed,themorevictimsareexploitedduetothevulnerability.Notethateventheshortestperiod(theoneforCVE-2015-1805)hasbeenlongerthan120days.
BaiduX-Lab
6
Figure4:Daysfromadvisorypublicationdatetonow(July2016)forthethreefamous"one-to-root-all"kernelvulnerabilities
Itisagainstouruser-agreementtoexploitthedevicestodetectwhetheravulnerabilityexistsornot.SowesimplycollectedthekernelversionandbuildtimestampfromnearlytwomillionsofdevicesinChinawithBaiduappsinstalled.Weassumethatifakernelwasbuiltearlierthantheadvisorydate,itishighlylikelythatitisunpatchedforthecorrespondingvulnerability;otherwiseitisassumedaspatched.ThisconservativeassumptionshouldunderestimatetherateofvulnerabledevicesbecausefewdevicevendorscancatchupwithGoogle’sAndroidSecurityAdvisories.AsshowninFigure5,thisconservativecountingstillyieldsalargeportionofvulnerabledevices.Itissadtoseethatsomanyusersarestillunderrootexploitattackevenaftermonthsoryearsofthevulnerability’sdisclosure.
Figure5:VulnerabilitystatisticscollectedfromChineseAndroiddevice
4.AdaptKpatch:AdaptiveKernelLivePatching
Howcanwesolvetheproblemthen?Toshortenthelongpatchingchain,boththeacademiaandindustryhaveproposedkernellivepatchingmethods.Representativeimplementationsincludekpatch[14],ksplice[15],kGraft[16],andLinuxupstream’slivepatch[17].Detailsmayvaryfordifferentsolutions,buttheyusuallysharethefollowingsteps:
1) Loadnewcodeintomemory,andmakeitaccessible(exported)toexistingcode;2) Performsafetycheck,toavoidthemixedcontext(old&newcodeinvokedinthesame
callstack);
0 200 400 600 800 1000
CVE-2015-1805PipeRoot
CVE-2015-3636PingPongRoot
CVE-2014-3153Towelroot
Dayssincetheadvisorypublicationdate
0%20%40%60%80%100%
CVE-2014-3153Towelroot
CVE-2015-3636PingPongRoot
CVE-2015-1805PipeRoot
Vulnerable NotVulnerable
BaiduX-Lab
7
3) Switchingexecutionfromoldcodetothenewcode.However,westillhavetwoproblemstoaddress–thefragmentationissueandthecapabilitymismatchingissue.Alltheexistingkernellivepatchingmechanismsrequiresourcecode.Thepatchingcodeisgeneratedbycomparingthedifferenceoftwobinaries,onecompiledfromtheoldsourcecodeandtheotherfromthepatchedsourcecode.Oncegenerated,thiscertainpieceofpatchingcodecanonlybeappliedtothecertainkernelbuild;itcannotbeinstalledtootherplatformsduetosymboldependency,etc.SoisthereawaytoautomaticallyadjustbinarypatchestoadapttodifferentdevicemodelswithdifferentAndroidkernelversions?Theanswerisyes.Inthe7thHITBConference[18],wehavealreadypresentedAdaptKpatchtoperformautomaticpatchadaptiontoallAndroiddevices,asshowninFigure6.
Figure6:Adaptivekernellivepatchingprocedureswithoutphonevendors’cooperation[18]
Tobebrief,whenourpatchingagentlandsonaphoneanddetectskernelvulnerabilitiesthatcanbeexploitedtogainroot,itwillnotifytheuseraboutthevulnerabilitiesandaskwhetherhe/shewantstofixit.Oncepermitted,thepatchingagentrootsthedeviceandcollectsnecessaryinformationneededforadaption,includingkernelversions,symboladdresses,symbolCRCs,etc.Next,dependingonwhetherthedeviceprovidesinsmodorthe(k)memdevice,theagenteitherdownloadsakernelmoduletemplateorabinarycodetemplateforpatching,andfillsthecollectedinfointothetemplatetogeneratetheadaptedpatch.Thisproceduresolvesthesymboldependenciesofthepatchandfulfillskernelchecks,sothegeneratedpatchcanbeinsertedintothekernelviainsmodor(k)memwithoutaproblem.Oncethepatchcanbeexecutedinthekernelmode,therestofthepatchingprocedureisthesameasotherexistingsolutionslikekpatch/ksplice/kGraftetc.Thisenablesthirdpartyvendors,whodonothaveaccesstotheexactsourcecodeofthedevicekernelanddrivers,toperformlivepatching.NotethatAdaptKpatchonlyperformshotpatching–itdoesnotmodifythebinariesonthefilesystem,soitdoesnotconflictwiththestaticintegrityprotectionmechanisms(suchastheSecureBoot).Onrebooting,allthepatchesaregonesotheframeworkshouldbelaunchedintheveryearlystageofthebootingprocessandreloadthepatches.Abootflagisusedtodetect
BaiduX-Lab
8
iflastbootingfailed.Inthatcase,AdaptKpatchwillperformfailoverwithoutloadingtheproblematichotpatches.Thisframeworkcanbefurtherimprovedifthereexistsajointeffortbetweenthedevicevendorandthethirdpartypatchdeveloper.Intheabovedesign,thepatchingagentneedstoprobekernelvulnerabilities.However,itisdifficulttopreciselyprobekernelbugswithoutdisturbinguserexperience.Soitwouldbebetterifthedevicevendorcanprovidealistofvulnerabilitiescorrespondingtoeachkernelbuild.Thisshouldbeeasyfordevicevendorssincetheypossessthesourcecode.Moreover,itwouldbeevenbetterifthedevicevendorcanintegrateapatchingmoduleinthekernel.Thissavesthethirdpartyfromrootingthedevice.Nevertheless,theseimprovementsarenotrequiredbutcanhighlyboosttheefficiency.
Figure7:Adaptivekernellivepatchingframeworkwithphonevendor'scooperation
Theframeworkwithdevicevendors’cooperationisshowninFigure7.Theuser-spaceagentcommunicatestocloudforvulnerabilitiesofthecurrentkernelbuild,anddownloadspatchtemplatesaccordingly.Afterpromptingtotheuserandgettingauthorized,itsendsthepatchestothekernelpatchingmodule.TheSELinuxpolicyenforcesthatonlytheagentcantalktothepatchingmodule.Thepatchesshouldbesignedsothatthekernelpatchingmodulecanrejectillegalcodepieces.Thepatchesshouldalsobeversionedsotheycanonlybeupgradedwithoutbeingdowngraded.Afterpassingtheverification,thekernelpatchingmodulethenexecutesthepatchandcanlaterundothepatch.Thekernelpatchingmoduleshouldalsomonitorthesystemstatusforpotentialissues(andperformpatchfailoverifthereisanissue).Nowthedevicevendorscanlaybackandnolongerneedtoworryaboutgeneratingpatches,andthemotivatedthirdpartiescanfocusonprovidingpatcheswithoutworryingaboutadaption.Everythingseemsperfect,exceptoneconcern–howcanthedevicevendorstrustthethirdpartypatchesbeforesigninganddeployingthem?Toensurethesecurityofthepatches,weneedamulti-stagevettingmechanism:
1) Vendorqualification:thepatchframeworkonlyacceptspatchessubmittedfrompre-qualifiedvendorswithsecurityexpertiseandgoodreputation.
2) Patchsecurityvetting:thesubmittedpatchesshouldbereviewedandsigned-offbyothermembersinthisalliancebeforedeployment.
BaiduX-Lab
9
3) Reputationranking:afterbeingdeployedonthedevices,thepatchesaresubjecttouserfeedback.Anyunstableorsuspiciouspatcheswillbeimmediatelyremovedandthecorrespondingvendor’sreputationwillbelowered.Thisissimilartotheappstore.
Thisalliance-basedvettingmechanismcansignificantlyreducebackdoorsandnewvulnerabilitiesintroducedbythepatches.Butaslongasthepatchesareinthenativeform(compiledfromCandexecutedirectlyinkernelmode),itdoesnoteliminatesecurityissues.Especiallywhencriticalvulnerabilitiesarefoundandthephonevendorsortheuserswanttodeploypatchesinafewdays,itisstillchallengingtothoroughlyreviewthebinarypatches.Thatiswhywehaveanalternative:LuaKpatch.
5.LuaKpatch:MoreFlexibility,YetMoreConstraint5.1DesignPrinciples
Ifvendorshaveenoughtime(e.g.,twoweeks)toreviewthepatchesandrunthoroughtestsagainstthepatches,itshouldbefairlysafetodeploythepatchesusingAdaptKpatchdescribedabove.However,ifcriticalvulnerabilitiesariseandneedtobehot-patchedintwodays,itisdangeroustoloadhastypatchesintomillionsofdevices.Soweneedamechanism:
1) powerfulenoughtoblockmostthreats;2) agileenoughforquickpatchgeneration;3) yetrestrictiveenoughtoconfinepossibledamagescausedbythepatches.
Tofulfilltherequirements,wecaninsertatype-safedynamiclanguageengine(suchasLua)intothekerneltoexecutepatches.Programswrittenindynamiclanguagesareeasytoupdateandarenaturally“jailed”inthelanguagevirtualmachine(VM).Thetypesafetyfeaturepreventsthepatchesfromintroducingnewvulnerabilitiesthatcanbeattacked.Thenhowshouldweexposethekerneltothepatchingenginetoensureminimumsurfaceexposedbutcapableenoughtodothepatchingwork?Afterexaminingmostoftherecentkernelexploits,onecanfindthatinordertotriggerthevulnerability,theattackerneedstofeedmaliciousdatainputsintothetargetfunction.ThisisillustratedinFigure8–regardlessoftheattacker’stricks,he/sheeventuallyneedstoinjectmaliciousinputtohijackthecontrolflowtoachievecodeexecution.Therefore,weactuallydonotneedtoreplacethewholefunction;ifwecanhookfunctionentriesorexternaldatareadingstovalidateinputdata,itissufficienttodetectmostofthethreats.Ifmaliciousinputdataareencountered,thevalidatorreturnsanerrorcode,sotheafterwardcontrolflowwillnaturallyfallintotheerrorhandlingpathinsteadoftheoriginalvulnerablepath.
BaiduX-Lab
10
Figure8:Kernelfunctionstakeinputfromeitherargumentsorexternaldatareading(e.g.,copy_from_user)asshownin(a).MostAndroidkernelexploitsinjectmaliciousinputintothetargetfunctionandhijackthecontrolflowtoachievearbitrarycodeexecution,asshownin(b).So,byhookingthedatainputentriesandvalidatingtheinputasshownin(c),wecanblockmostof
thekernelexploits.
Tobemorespecific,wehavethefollowingrestrictions:1) Thepatchcanhookatargetfunction’sentry;2) Incombinationwith1),withinthetargetfunction,thepatchcanhooktheinvokingpoint
orreturningpointoffunctionsthatreturnastatuscode(e.g.,copy_from_user);3) Thepatchcanreadanythingthatcanberead(registers,stacks,heaps,code,etc.,as
longasitdoesnottriggerfaults),butcannotmodifyoriginalkernelmemory(nowrite,andnodatacanbesentout);
4) Afterjudgingwhethertheinputismaliciousornot,thepatchcanreturnspecificerrorcodes.
Thefirstpolicyisstraightforward.Itforcesthepatchdevelopertoexplicitlyclaimthetargetfunction,andonlycheckstheargumentspassedintoit.Thepatchreviewercanthusimmediatelyunderstandwhichfunctionistobehookedandwhy.Thethirdandfourthpoliciesarealsoreasonable,whichprovidethecapabilitytodetectattacksbutpreventingmodifications.Butwhatisthemeaningofthesecondrestriction?Tomakeitintuitive,arunningexampleisshowninFigure9.Thevulnerablefunctionfuncallsdatareadingfunctionsfooandbar.Thefunctionfooreadsdataintoabufferandreturnssuccessorfailure,whilebarreturnsapointertoastructure.Afterinvokingfoo,funonlyusesaconditionalstatement1tohandlethereturnvalueoffoo,sofoosatisfiestherule.Onthecontrary,afterinvokingbar,funinvokesafunctionpointedbyafieldinthestructurereturnedbybar,sobarfailstosatisfy
1Conditionalchecksincludestatementslikeif/else,switch/case,do/while,for,etc.
BaiduX-Lab
11
therestriction.Asaresult,weallowthepatchtohooktheinvokingpointandthereturningpointoffoo2,butforbidhookingthoseofbar.
Figure9:Arunningexampletoillustratewhichfunctionscanbehookedandwhichcannot
Wegenerateawhitelistofkernelfunctionswhosereturnvalueisastatuscodebasedongeneralkernelsourcecode.Onlyfunctionsonthiswhitelistcanbehookedwithinthetargetfunction.Withthisrestriction,weeliminatereturnvaluebasedcontrolflowmanipulation.Anothergreatbenefitofthisrestrictionisthatwhenthevalidatordetectsamaliciousinputandreturnsanerrorcode,theconditionalcheckafterwardswillnaturallyswitchtotheerrorhandlingbranch.Thisnotonlyavoidstriggeringthevulnerablecodebranch,butalsoavoidscrashingthekernel.WecallvulnerabilitiesthatcanbefixedbysimplyhookingthevulnerablefunctionentryasTypeIvulnerabilities.ThosethatneedtoalsohookinvokedfunctionsareclassifiedasTypeIIvulnerabilities.InSection5.3,wewillshowthenumbersofthesetwodifferenttypesofvulnerabilities.5.2Implementation
Weimplementthememory-safedynamiclanguageenginebasedonLuafollowingtherestrictionrulesdescribedabove,namedasLuaKpatch.Luacertainlysatisfiesmemorysafetyandhasmanydynamicflexibilities.Itistiny,fast,simple,easytoextend,withgreaterrorhandling,andhasthebestintegrationwithC.InordertointegrateitintotheAndroidkernel,wefollowedmanypracticesfromthelunatik-ngproject[19].Forexample,numbersintheoriginalLuaimplementationareinfloating-pointtype.ButLinuxkerneldoesnotsupportfloating-pointarithmetic,andpatchesbarelyrelyonit.Sonumbersshouldbedefinedasintegers.Moreover,unnecessaryLualibrarieslikefileoperationsarestrippedawaytoreducethecodebasesize.
2Notethatthepatchhooksfun’scallinginstructionandthereturningsite,notfoo’sentryinstructionandreturninginstruction.Thisavoidsalltheinvocationstofoogethooked,whichisexpensive.
BaiduX-Lab
12
TheLine-of-Code(LoC)ofLuaKpatchisroughly11K.Amongthem,10KareLuaengine’scode,andthecorepatchinglogiconlytakeslessthan600LoC.LuaKpatchiscompiledasan800KBkernelmodule.Itcanbepre-shippedinthekernelifthephonevendorcooperates.Otherwise,itcanbeshippedasastandalonekernelmoduleandcanbeloadedusingtheadaptivemethodintroducedinAdaptKpatch.Onceloadedintothekernel,itlaunchesaLuaVMinstanceandusesakernelworkqueuetoprocesspatchrequests.WeimplementthefollowinginterfacefamiliesforLuatooperateon:
1) Symbolsearching:takeasymbolstringandreturntheaddress.2) Hooking:takeanaddressandhookonit.Thehookingisachievedbyinsertinga
trampoline.Oncetriggered,thetrampolinesavesthecurrentcontext(registers,stack,etc.)andinvokesthedesignatedLuapatchinghandler.
3) Typedreading:takeanaddress,validateiftheaddressisreadable,thenreturnthetypedvaluetoLua.
4) Threadinfofetching:returnthecurrentthreadinformation,suchasthreadid,etc.
Figure10:SampleLuapatchtofixoneofthevulnerableconditionsofCVE-2014-3153,knownas“Towelroot”
BasedontheseAPIs,thepatchcanbeassimpleasshowninFigure10.OnLine14,thevulnerablefunctionfutex_requeueistargeted,andgetshookedonLine15.Thehookingprocessinsertsatrampolineattheentranceofthisfunction,whichsavesthecontext(registersandstackcontent)andinvokesthekpatcherhandler.ThehandlerrecognizesthecorrespondingcheckviathedesignatedpatchID,andperformsthenecessarychecksbasedonthesavedcontext.Ifvulnerableconditionsaredetected,thepatchhandlerreturnsanerrorcode;otherwiseitreturnszero.WhentheLuapatchhandlerreturns,theexecutionturnsbacktothetrampoline.Incaseoferror,thetrampolinereturnstheerrorcodetothecalleroffutex_requeue;otherwiseitresumesnormalexecutionintofutex_requeue.SimilartoAdaptKpatch,LuaKpatchonlyperformshotpatching,soitdoesnotconflictwiththestaticintegrityprotectionmechanismslikeSecureBoot.Onrebooting,theframeworkshouldbelaunchedintheveryearlystagetoreloadthepatches.Also,itneedstofallbacktonormalbootingifhotpatchescauseproblems.
BaiduX-Lab
13
5.3EfficacyEvaluation
Wecollectrecentwell-knownAndroidkernelvulnerabilitieswithpublicexploitsorcrashingPoCinTable2.ItturnsoutthatallthevulnerableconditionsofthemcanbecapturedbyLuaKpatch.ThepercentagesofTypeIandTypeIIvulnerabilitiesareshowninFigure11.Themajorityofthevulnerabilitiescanbefixedsimplybyhookingandperforminginputvalidationatthefunctionentry.
CVE-2012-4220 CVE-2013-6123 CVE-2015-3636CVE-2012-4221 CVE-2013-6282 CVE-2015-6619CVE-2012-4222 CVE-2014-3153 CVE-2015-6640CVE-2013-1763 CVE-2014-4321 CVE-2016-0728CVE-2013-2094 CVE-2014-4322 CVE-2016-0774CVE-2013-2596 CVE-2015-0569 CVE-2016-0802CVE-2013-2597 CVE-2015-1805 CVE-2016-2468
Table2:AndroidrootvulnerabilitiesthathavebeenverifiedtobeprotectablebyLuaKpatch.MostofthevulnerabilitiesareTypeIvulnerabilities(thosethatcanbepatchedbysimplyhookingtheentryofthevulnerablefunctions),butthehighlighted/colored
onesareTypeIIvulnerabilities(thosethatalsoneedtohooktheinvocationsthatreturnstatuscode).
Figure11:All21vulnerabilitiesthatwecollectedcanbepatchedbyLuaKpatch.Amongthem,16areTypeIvulnerabilities,and5
areTypeIIvulnerabilities.So76%ofthevulnerabilitiescanbefixedbyhookingandcheckinginputatthefunctionentry.
Forexample,forCVE-2013-1763,thesourcecodepatchisshowninFigure12.LuaKpatchcanpatchitbyhookingtheentryofthe__sock_diag_rcv_msgfunction,gettingthenlhargument,obtainingreqfromnlh,andthencheckingwhethertheconditionreq->sdiag_family >= AF_MAXissatisfied.Ifthisistrue,itisanexploitconditionandthepatchshouldreturnanerror.
Figure12:ThesourcecodepatchforCVE-2013-1763
TypeI16
TypeII5
BaiduX-Lab
14
Asanotherexample,thesourcecodepatchforCVE-2013-6123isshowninFigure13.Thecheckingconditionreliesonthecontentofu_isp_event,whichisobtainedfromtheuserspace(showninFigure14).SoLuaKpatchcannotsimplyvalidatetheexploitconditionbyhookingtheentryofmsm_ioctl_server.Luckily,copy_from_userreturnsstatuscode,soLuaKpatchallowstohookcopy_from_userinvocationswithinmsm_ioctl_server.Theremainingchecksarestraightforwardsoweomittheelaboration.
Figure13:ThesourcepatchforCVE-2013-6123
Figure14:u_isp_eventisobtainedfromcopy_from_user
However,notallvulnerabilitiescanbeperfectlysolved.Forexample,forCVE-2015-3636(knownas“PingPongRoot”),theofficialpatchistoaddsk_nulls_node_initintoping_unhash.LuaKpatchdoesnotallowpatchestoachieve“hook-anywhere”and“arbitrary-code-execution”forsecurityconsideration.So,asanalternativethepatchesshouldinsertanargumentvalidationatthefunctionentryofping_unhash,checkingifsk->sk_nulls_node.pprevequalsto0x200200(LIST_POISON2).Ifthisexploitconditionisdetected,thepatchreturnsanerrorwithoutexecutingintoping_unhash.Notethatthisintroducessideeffects,becausetheintendedping_unhashfunctionalitiesaredroppedincaseofexploits.Luckily,kernelexploitsusuallytargetatcodepathsthatcommontasksdonottrigger(e.g.,ping_unhashonAndroidisbarelyinvoked),andthiskindofsideeffectsdoesnotbringinseriousconsequences.Wedidanexperimentbyapplyingthispatchondifferentdevices(Nexus5,SamsungS6,etc.)andverifiedthatthePingPongRootcanbesuccessfullydefendedagainst.Aftertwoweeks’normalusage(Internetbrowsing,playinggames,etc.)withoutrebooting,thesedevicesarestillrunningsmoothlywithoutaproblem.Afterall,havingsomenone-crashingsideeffectssuchasmemoryleakageiswaybetterthan
BaiduX-Lab
15
beingexploited.Evenintheworstsituation,wecanfallbacktothenormalAdaptKpatchmechanism.
5.4PerformanceEvaluation
LuaKpatchinsertsextravalidationchecksintovulnerablekernelfunctions,butsincetheexploitedfunctionsareusuallynotfrequentlyinvoked(heavilyexecutedcodeusuallyundergoesmorethoroughtesting),theperformanceshouldnotbeimpactedtoomuch.WeevaluatedthewholesystemperformanceoverheadusingCF-Bench[20]onNexus5withAndroid4.4.Fourconditionsweretestedforcomparison:
1) beforegettinganypatches2) withtheTowelrootvulnerabilitypatchedbyLuaKpatch3) withthePingPongRootvulnerabilitypatchedbyLuaKpatch4) withbothvulnerabilitiespatched
Theaverageperformancescorewasobtainedfrom20measurementsineachtest.TheresultisshowninFigure15–thereisnoobservableoverheadincurredbyLuaKpatch.ThisisasexpectedsincethepatchedfunctionsarebarelycalledduringAndroidnormalexecution.
Figure15:PerformancescoresobtainedfromCF-Bench.Thescoreshavesmalldeviations,whicharewithinCF-Bench’snormal
fluctuationrange.
Nevertheless,wearestillinterestedintheoverheadofLuaKpatchintheworstcases.Morespecifically,wewanttomeasuretheoverheadofeachLuaKpatchvalidation.Todoso,wemeasuredtheexecutiontimeofchmodsystemcallbeforeandafterpatchingitwithaseriesofdummypatches.Thesystemcallisexplicitlyinvokedfor1000timesforeachmeasurement,andtheaveragetimeiscalculatedfrom20measurements.AsshowninFigure16,whennopatchisapplied,thesystemcallitselftakesabout100.7microseconds.ThenweappliedfourtestingpatchestomeasurethecostofLuaKpatch:
17473.25 17551.75 17521.4 17482
0
5000
10000
15000
20000
Normal Patched(Towelroot) Patched(PingPongRoot) Patched(bothvulnerabilities)
PerformanceScore
BaiduX-Lab
16
1) Whenappliedwithapatchthatsimplyreturnszero,theoverheadis0.42microseconds.Thisreflectsthecostofthetrampolineexecutiontime,namelythecontextsaving/restoringplusthekernel-to-LuaKpatch/LuaKpatch-to-kerneltransitiontime.
2) Whenappliedwithapatchthatcontainsan“if/elseif/else”conditionstatement.Thispatchaddsanoverheadof0.98microsecondstothesystemcall.
3) Whenappliedwithapatchwhichconsistsofamemoryread,itaddsanoverheadofaround0.82microsecondstothesystemcall.
4) Lastly,tosimulateacomplicatedsituation,wewroteapatchwithamixtureofassignments,memoryreadsandconditionalstatements.Theoverheadisabout3.74microseconds.Thatislessthan4%ofthenormalchmodexecutiontime.
Figure16:Executiontimeofchmodwith/withoutthepatches
Fromtheaboveexperiments,wecanseethatacommonLuaKpatchvalidationcheckaddsanoverheadunder5microseconds.Becausesystemcallsarenotinvokedallthetime,theimpacttotheoverallsystemperformanceshouldbeevenless.WecountedallsystemcallinvocationsontheNexus5withAndroid4.4for1minutewhenausernormallybrowsesInternetusingChrome.Amongallthetriggeredsystemcalls,gettimeofdaywasthemostly-calledone,whichgottriggeredforabout110,000times.Theoverallperformanceoverheadcanbeestimatedas5µs*110,000/1min»0.9%,whichisquitesmall.Tosummarize,LuaKpatchonlyintroducesnegligibleperformanceoverhead.Asanongoingwork,wearemigratingLuaKpatchtoLuaJIT[22],whichshouldfurtherimprovetheperformance.
6.Conclusion
Inthiswork,wediscussedwhyAndroidkernelvulnerabilitiescanlastsolong.Totacklethisproblem,weintroducedLuaKpatchandAdaptKpatch.Bothframeworkscansavedevelopersfromtediouspatchportingwork.Also,becausetheyareopenplatforms,patchescanbe
100.7 101.12 101.68 101.52 104.44
0
20
40
60
80
100
120
Nopatch Patchedwithadirectreturn
Patchedwithaconditionalcomparison
Patchedwithamemoryread
Patchedwithmixedoperations
ExecutionTime(Microseconds)
BaiduX-Lab
17
providedfromvariousvendors.Asaresult,Androidkernelpatchingcirclecanbegreatlyshortened.AsshowninFigure17,withLuaKpatch,criticalvulnerabilitiescanbepatchedinafewdays.Beforethecoldpatchesarerolledout,orincasesomevulnerabilitiescannotbeperfectlysolvedbyLuaKpatch,AdaptKpatchcanbeutilizedtofixtheissues.LuaKpatchisdefinitelysaferthanAdaptKpatchduetomorerestrictedconstraints.Strangeasitmaysound,bothLuaKpatchandAdaptKpatcharemuchsaferthanthetraditionalcoldpatching.Thisisbecausecoldpatchesarepermanentmodifications.Ifthereissomethingwrongwiththepatches,millionsofdeviceswillbebricked.LuaKpatchandAdaptKpatch,however,onlyloadpatcheslivelyoneachreboot,andcaneasilyfallbacktonormalbootingifissuesareencountered.
Figure17:Thepatchingcircleintheopencollaborativepatchingecosystem.Fromlefttoright,ittakesmoretimeforpatchestolandonuserdevicestotakeeffect.Andfromlefttoright,thesafetylevelalsodecreases.NotethatAdaptKpatchcanperfectly
fixmoreissuesthanLuaKpatch,sowhenLuaKpatchisnotanidealchoice,AdaptKpatchcanbeagreatalternative.
BasedonLuaKpatchandAdaptKpatch,wecallfortheAndroidecosystemtoestablishapatchingalliance.Thisallianceconsistsofdevicevendors,securityvendors,andotherpartiesintheAndroidopensourcecommunities.Thisalliancewillbeofgreatsignificance,inthat:
1) Thenumberandthecomplexityofkernelvulnerabilitieskeepincreasing,somorejointeffortmakesiteasiertobattleagainstthem.
2) IntheAdaptKpatchscheme,patchescanbevettedandcross-validatedbyqualifiedalliancemembers.
3) Lastbutmostimportantly,allvendorscanjointogethertodevelopapatchingstandardinsteadofimplementingdifferentvariants.Ifdifferenthotpatchingmechanismsexist,itintroducesanotherlayeroffragmentation.
Everypartyintheecosystemshouldbewellmotivated–thedevicevendorwillhavemoresecureproductsthusmoreusersandsaleswithoutoverheadspentonsecurityR&D.Securitypatchproviderswillgainreputationandprofits(rewardsandbrandfame)ontheotherhand.Finally,thisframeworkcanbeeasilyextendedandappliedtogeneralLinuxplatforms.Webelievethatimprovingthesecurityofthewholeecosystemisnotthedreamofourown.Wecallformoreandmorepartiestojoininthisefforttofighttheevilstogether.
References
[1] http://www.cmcm.com/blog/en/security/2015-09-18/799.html
BaiduX-Lab
18
[2] https://www.fireeye.com/blog/threat-research/2015/10/kemoge_another_mobi.html[3] https://www.bluecoat.com/security-blog/2016-04-25/android-exploit-delivers-dogspectus-
ransomware[4] https://blog.checkpoint.com/wp-content/uploads/2016/07/HummingBad-Research-
report_FINAL-62916.pdf[5] HangZhang,DongdongShe,andZhiyunQian.AndroidRootanditsProviders:ADouble-Edged
Sword.InProceedingsofthe22ndACMSIGSACConferenceonComputerandCommunicationsSecurity(CCS'15)
[6] https://bugs.chromium.org/p/project-zero/issues/detail?id=734&can=1&sort=-id[7] http://www.howtogeek.com/163958/why-do-carriers-delay-updates-for-android-but-not-iphone[8] http://opensignal.com/reports/2015/08/android-fragmentation[9] https://developer.android.com/about/dashboards/index.html[10] https://github.com/torvalds/linux/commit/e9c243a5a6de0be8e584c604d353412584b592f8[11] https://source.android.com/security/bulletin/2015-09-01.html[12] https://github.com/torvalds/linux/commit/f0d1bec9d58d4c038d0ac958c9af82be6eb18045[13] http://source.android.com/security/advisory/2016-03-18.html[14] https://github.com/dynup/kpatch[15] https://www.ksplice.com/doc/ksplice.pdf[16] http://events.linuxfoundation.org/sites/events/files/slides/kGraft.pdf[17] http://lxr.free-electrons.com/source/include/linux/livepatch.h[18] https://conference.hitb.org/hitbsecconf2016ams/sessions/adaptive-android-kernel-live-patching[19] https://github.com/lunatik-ng/lunatik-ng[20] https://play.google.com/store/apps/details?id=eu.chainfire.cfbench&hl=en[21] https://httpd.apache.org/docs/2.4/programs/ab.html[22] http://luajit.org
