adaptive kernel live patching: an open collaborative...

of 18/18
Baidu X-Lab 1 Adaptive Kernel Live Patching: An Open Collaborative Effort to Ameliorate Android N-day Root Exploits Yulong Zhang, Yue Chen, Chenfu Bao, Liangzhao Xia, Longri Zhen, Yongqiang Lu, and Tao Wei Baidu X-Lab 1. Background Android kernel vulnerabilities are dangerous. Attackers can exploit kernel vulnerabilities to root Android devices and achieve malicious goals. If the kernel gets compromised, all security mechanisms relying on kernel integrity (e.g. app sandboxing, payment/fingerprint framework, etc.) will be broken. TrustZone, the last line of defense for Android devices, will also be threatened as the compromised kernel enables the attacker to inject malicious payloads into TrustZone. So, it is ideal to get rid of kernel vulnerabilities. However, more and more kernel vulnerabilities have been unveiled each month (shown in Figure 1). On one hand, this is a good trend indicating more and more effort has been spent on securing the Android kernel; on the other hand, kernel vulnerabilities that have been disclosed but remain unfixed have become the largest threat for Android users. Having been in the spotlight for weeks or even months, they usually have public and stable exploits, and thus become underground businesses’ favorite. For example, from the recent popular malware incidents with global impact [1-4], one can always find a root toolkit inside. Such root exploits are either from public Proof-of-Concept (PoC), or copied from one-click root apps. Consequences of these malware include frauds, credential leakage, fingerprint leakage, losing money from banking/payment/financial accounts, or even remote controls. Figure 1: Number of kernel vulnerabilities disclosed in monthly Android Security Bulletin 1 1 3 4 4 7 15 19 66 2015/09 2015/12 2016/01 2016/02 2016/03 2016/04 2016/05 2016/06 2016/07 Monthly Disclosed Number of Kernel Vulnerabilities

Post on 16-Apr-2018

213 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

  • 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,andthusbecomeundergroundbusinessesfavorite.Forexample,fromtherecentpopularmalwareincidentswithglobalimpact[1-4],onecanalwaysfindaroottoolkitinside.SuchrootexploitsareeitherfrompublicProof-of-Concept(PoC),orcopiedfromone-clickrootapps.Consequencesofthesemalwareincludefrauds,credentialleakage,fingerprintleakage,losingmoneyfrombanking/payment/financialaccounts,orevenremotecontrols.

    Figure1:NumberofkernelvulnerabilitiesdisclosedinmonthlyAndroidSecurityBulletin

    1 1 3 4 47

    15 19

    66

    2015/09 2015/12 2016/01 2016/02 2016/03 2016/04 2016/05 2016/06 2016/07

    MonthlyDisclosedNumberofKernelVulnerabilities

  • BaiduX-Lab

    2

    PeoplecommonlyclaimthatusingAndroidiseasiertobeattacked,orAndroidislesssecurethaniOS.Actually,ifwesimplycomparethekernelvulnerabilitiesdisclosedineachiOSrelease(Table1),itappearsthatiOSkernelvulnerabilitydisclosurefrequencyisnotlessthanAndroids.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

    bornasbullet-proof;itismoresecurejustbecauseitcangettimelypatchesinalargescale.

    2.WhyAreAndroidKernelVulnerabilitiesLong-lasting?

    WhyAndroidcannotgetthesekernelvulnerabilitiespatchedinatimelymannerlikeiOS?Therearemainlythreecauses:

    1) Thelongpatchingchaindelaysthepatcheffectivedate;2) Fragmentationmakesitchallengingtoadaptthepatchestoalldevices;3) Capabilitymismatchingbetweendevicevendorsandsecurityvendors.

    Thesecausesarediscussedindetailbelow.2.1TheLongPatchingChain

    AsshowninFigure2,itusuallytakesmonthsorevenyearsforapatchtopassallstagesandlandonusersphones,nottomentionthatsomepatchesmaybediscardedinoneofthesestages.Forexample,inanacademicstudy[5],theauthorsclaimthatfromreverse-engineeringafamousrootapp,theyfoundatleast10kernelexploitsthathaveneverbeenreportedtovendors.Inthiscase,thevulnerabilitieshavebeenidentifiedandmadepublic(sinceeveryonecanreverse-engineerthatfamousrootapptounderstandthevulnerabilities,orevenreusetherootexploitlibrarydirectly),butthevendorsdidnotknowtheirexistence,sothereisnopatchreleasedthroughtheofficialpatchingchanneltopatchthem.Thisistheschemewherethepatchingchainstopsattheveryfirststage.

  • BaiduX-Lab

    3

    Figure2:ThelongpatchingcircleofAndroidkernelvulnerabilities

    Asanotherexample,GoogleProjectZeroidentifiedabug[6]butsomehowitwasnotappliedtovendorskernelbranch.Soaccordingtothispost,themajorityofAndroidkernelsbasedon3.4or3.10arestillaffecteddespitethepatchbeingavailablefor6months.Thisistheschemewherethepatchingchaingotdelayedbeforereachingthethirdstage.Thefirstthreestepscouldbeskippedifthephonevendorsarewillingtoallocateenormousresourcesandmanpowertoidentifykernelvulnerabilitiesandreleasepatchestimely.However,thepatchingchainwouldstillbedelayedbythecarriers[7],whoneedtothoroughlytestwhetheraproposedpatchaffectsthestabilityandservicequalityofthecarrierphones.Finally,whenanOver-The-Air(OTA)patcharrivesatthedevices,usersmaynotbewillingtotakethepatchimmediatelysincemostofthecoldpatchesrequirephonerebootingtobecomeeffective.Sotheconcernofinterruptinguserexperiencefurtherdelaysthetraditionalpatcheseffectivedate.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,theworldslargestAndroidmarket,China,blocksnetworkaccesstoGoogle,soChinesedevicescannotobtainOTApatchesdirectlyfromGoogle.Duetothesamereason,ChinesedevicescannotreporttheirpatchingleveltoGoogle,thusGooglesAndroidversionstatisticsdonotincludeChinesedevicesiftheydo,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.Theycanalsoadaptthepatchesbasedonthesourcecodetheypossessitistedious,butstillfeasible.Butasmentionedabove,theirfirstpriorityisnottopatchthedevicestobullet-proof.Moreover,exploitsanddefensesarenottheirareaofexpertise.Onthecontrary,othershaveinteresttoprovidetimelypatchesfordevices,likesecurityvendors(forfameandprofit)anddevelopersofappsrelyingonAndroidsecurity(forriskcontrol).Theyhavebetterunderstandingofthereal-worldthreatstoo.However,sincedevicevendorsusuallydontpublishtheexactup-to-datekernelsourcecodeforalldevices,itisextremelydifficultforthirdpartiestoadaptpatchesforalldevices.Itisalsochallengingforthirdpartiestoapplypatchessincetheydonthaveenoughprivileges.WecallthisdilemmaasCapabilityMismatchingthosecapabletoapplythepatchdonothavehighestinterestorexpertisetogeneratethepatch,whilethosecapabletogeneratethepatchdonothavecapabilitytoadaptandapplythepatches.ThisisthethirdbutstillanimportantcauseoftheAndroidsvulnerabilitiesremainingunfixedforalongtime.

  • BaiduX-Lab

    5

    Nowthatwehaveidentifiedthethreemajorcauses,wecanexplainwhyAndroidappearstobelesssecurethaniOS:

    1) Applecontrolstheentiresupplychain,fromhardwaretosoftware,andhavemorerightsspeakingtocarriers,soitspatchingchainissignificantlyshorter.

    2) ThenumberofiOSdevicevariantsismuchsmallerthanAndroids,andApplehasthesourcecodeforthem,soitismucheasierforAppletogenerateandadaptpatchesforallvariants.

    3) Fromtimetotime,Applerefusestosignoldversions,sodevicescanonlybeupgradedanddowngradingisnotpossible.

    3.CaseStudiesofLong-livedKernelVulnerabilities

    Hereweusethreewidelyexploitedcross-platformkernelvulnerabilitiesforcasestudies.ThefirstoneisCVE-2014-3153,knownasTowelroot.Thevulnerabilityisduetothatthefutex_requeuefunctioninkernelthrough3.14.5doesnotensurethatcallshavetwodifferentfutexaddresses,whichallowslocaluserstogainprivileges.AtitstimebeingtherewasnoAndroidSecurityBulletinissued,soweconservativelycountthefirst-knowndateasthetimewhenthisvulnerabilitywasfirstlypatchedintheupstreamkernel:June3,2014[10].ThesecondoneisCVE-2015-3636,knownasPingPongRoot.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.ThisconservativeassumptionshouldunderestimatetherateofvulnerabledevicesbecausefewdevicevendorscancatchupwithGooglesAndroidSecurityAdvisories.AsshowninFigure5,thisconservativecountingstillyieldsalargeportionofvulnerabledevices.Itissadtoseethatsomanyusersarestillunderrootexploitattackevenaftermonthsoryearsofthevulnerabilitysdisclosure.

    Figure5:VulnerabilitystatisticscollectedfromChineseAndroiddevice

    4.AdaptKpatch:AdaptiveKernelLivePatching

    Howcanwesolvetheproblemthen?Toshortenthelongpatchingchain,boththeacademiaandindustryhaveproposedkernellivepatchingmethods.Representativeimplementationsincludekpatch[14],ksplice[15],kGraft[16],andLinuxupstreamslivepatch[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,westillhavetwoproblemstoaddressthefragmentationissueandthecapabilitymismatchingissue.Alltheexistingkernellivepatchingmechanismsrequiresourcecode.Thepatchingcodeisgeneratedbycomparingthedifferenceoftwobinaries,onecompiledfromtheoldsourcecodeandtheotherfromthepatchedsourcecode.Oncegenerated,thiscertainpieceofpatchingcodecanonlybeappliedtothecertainkernelbuild;itcannotbeinstalledtootherplatformsduetosymboldependency,etc.SoisthereawaytoautomaticallyadjustbinarypatchestoadapttodifferentdevicemodelswithdifferentAndroidkernelversions?Theanswerisyes.Inthe7thHITBConference[18],wehavealreadypresentedAdaptKpatchtoperformautomaticpatchadaptiontoallAndroiddevices,asshowninFigure6.

    Figure6:Adaptivekernellivepatchingprocedureswithoutphonevendorscooperation[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.NotethatAdaptKpatchonlyperformshotpatchingitdoesnotmodifythebinariesonthefilesystem,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

    TheframeworkwithdevicevendorscooperationisshowninFigure7.Theuser-spaceagentcommunicatestocloudforvulnerabilitiesofthecurrentkernelbuild,anddownloadspatchtemplatesaccordingly.Afterpromptingtotheuserandgettingauthorized,itsendsthepatchestothekernelpatchingmodule.TheSELinuxpolicyenforcesthatonlytheagentcantalktothepatchingmodule.Thepatchesshouldbesignedsothatthekernelpatchingmodulecanrejectillegalcodepieces.Thepatchesshouldalsobeversionedsotheycanonlybeupgradedwithoutbeingdowngraded.Afterpassingtheverification,thekernelpatchingmodulethenexecutesthepatchandcanlaterundothepatch.Thekernelpatchingmoduleshouldalsomonitorthesystemstatusforpotentialissues(andperformpatchfailoverifthereisanissue).Nowthedevicevendorscanlaybackandnolongerneedtoworryaboutgeneratingpatches,andthemotivatedthirdpartiescanfocusonprovidingpatcheswithoutworryingaboutadaption.Everythingseemsperfect,exceptoneconcernhowcanthedevicevendorstrustthethirdpartypatchesbeforesigninganddeployingthem?Toensurethesecurityofthepatches,weneedamulti-stagevettingmechanism:

    1) Vendorqualification:thepatchframeworkonlyacceptspatchessubmittedfrompre-qualifiedvendorswithsecurityexpertiseandgoodreputation.

    2) Patchsecurityvetting:thesubmittedpatchesshouldbereviewedandsigned-offbyothermembersinthisalliancebeforedeployment.

  • BaiduX-Lab

    9

    3) Reputationranking:afterbeingdeployedonthedevices,thepatchesaresubjecttouserfeedback.Anyunstableorsuspiciouspatcheswillbeimmediatelyremovedandthecorrespondingvendorsreputationwillbelowered.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.Programswrittenindynamiclanguagesareeasytoupdateandarenaturallyjailedinthelanguagevirtualmachine(VM).Thetypesafetyfeaturepreventsthepatchesfromintroducingnewvulnerabilitiesthatcanbeattacked.Thenhowshouldweexposethekerneltothepatchingenginetoensureminimumsurfaceexposedbutcapableenoughtodothepatchingwork?Afterexaminingmostoftherecentkernelexploits,onecanfindthatinordertotriggerthevulnerability,theattackerneedstofeedmaliciousdatainputsintothetargetfunction.ThisisillustratedinFigure8regardlessoftheattackerstricks,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) Thepatchcanhookatargetfunctionsentry;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.

    2Notethatthepatchhooksfunscallinginstructionandthereturningsite,notfoosentryinstructionandreturninginstruction.Thisavoidsalltheinvocationstofoogethooked,whichisexpensive.

  • BaiduX-Lab

    12

    TheLine-of-Code(LoC)ofLuaKpatchisroughly11K.Amongthem,10KareLuaenginescode,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,knownasTowelroot

    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(knownasPingPongRoot),theofficialpatchistoaddsk_nulls_node_initintoping_unhash.LuaKpatchdoesnotallowpatchestoachievehook-anywhereandarbitrary-code-executionforsecurityconsideration.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.Aftertwoweeksnormalusage(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.TheresultisshowninFigure15thereisnoobservableoverheadincurredbyLuaKpatch.ThisisasexpectedsincethepatchedfunctionsarebarelycalledduringAndroidnormalexecution.

    Figure15:PerformancescoresobtainedfromCF-Bench.Thescoreshavesmalldeviations,whicharewithinCF-Benchsnormal

    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) Whenappliedwithapatchthatcontainsanif/elseif/elseconditionstatement.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.Theoverallperformanceoverheadcanbeestimatedas5s*110,000/1min0.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.

    EverypartyintheecosystemshouldbewellmotivatedthedevicevendorwillhavemoresecureproductsthusmoreusersandsaleswithoutoverheadspentonsecurityR&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