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