1WediscoveredelevennewattacksandwecoveranattackforSirithatwasreleasedinpublicasexploitationofaccessibilityinOS2DisclosurewereportedallvulnerabilitiesthatwefoundtotheOSvendors Figure1Generalarchit ID: 347056
Download Pdf The PPT/PDF document "iOS6,andAndroid4.4.Wewereabletoidentifyt..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
iOS6,andAndroid4.4.Wewereabletoidentifytwelve1attacks2thatcanbypassmanystate-of-the-artdefensemechanismsdeployedontheseOSs,includingUAC,theYamasecuritymodule,theiOSAppsandbox,andtheAndroidsandbox.Whendesigningnewinterfacesthatprovideaccesstocomput-ingsystems,onemustensurethatthesenewfeaturesdonotbreakexistingsecuritymechanisms.However,currentdesignsandimple-mentationsofaccessibilitysupporthavefailedtomeetthisrequire-ment.Ouranalysisshowsthatcurrentarchitecturesforprovidingaccessibilityfeaturesmakeitextremelydiculttobalancecompat-ibility,usability,security,and(economic)cost.Inparticular,wefoundthatsecurityhasreceivedlessconsiderationcomparedtotheotherfactors.Undercurrentarchitectures,thereisnotasingleOScomponentthathasalltheinformationnecessarytoenforcemean-ingfulsecuritypolicy;instead,thesecurityofaccessibilityfeaturesdependsonsecuritychecksimplementedintheassistivetechnology,theOS,andtheapplications.Unfortunately,inourevaluation,wefoundthatsecuritychecksareeitherentirelymissedorimplementedincorrectly(orincompletely)atalllevels.Basedonourndings,webelieveafundamentalsolutiontotheproblemwillinvolveanewarchitecturethatisdesignedwithsecurityinmind.Proposingthisnewarchitectureisbeyondthescopeofourwork.Instead,wepro-poseseveralrecommendationsthatworkundercurrentarchitecturestoeithermaketheimplementationofallnecessarysecuritycheckseasierandmoreintuitive,ortoalleviatetheimpactofmissing/incor-rectchecks.Wealsopointoutsomeopenproblemsandchallengesinautomaticallyanalyzinga11ysupportandidentifyingsecurityvulnerabilities.Insummary,thispapermakesthefollowingcontributions:WeperformedasecurityevaluationofaccessibilitysupportforfourmajorOSs:Windows,UbuntuLinux,iOS,andAn-droid;Wefoundseveralnewvulnerabilitiesthatcanbeexploitedtobypassmanystate-of-the-artdefensemechanismsdeployedonthesesystems,includingUACandapplicationsandboxes;Weanalyzedtherootcauseofthesevulnerabilitiesandpro-posedanumberofrecommendationstoimprovethesecurityofa11ysupport;Weshowedthatthecurrentarchitecturesforprovidingacces-sibilityfeaturesareinherentlyawed,becausenosingleOScomponentisabletoimplementasecuritypolicy:securitychecksattheassistivetechnology,theOS,andtheapplicationmustbeimplementedcorrectly;failureinanyofthesechecksintroducesvulnerabilities.Therestofthispaperisorganizedasfollows.Section§2givesabriefbackgroundofaccessibilitysupport.Section§3discussessecu-rityimplicationsofaccessibility.Section§4presentstheevaluationresults,i.e.,newvulnerabilitiesandattacks.Section§5discussesthelimitationsofourattacks,therootcauseofthevulnerabilities,andcomplexityoftheproblem.Section§6comparesthisworkwithrelatedworks.Section§7concludesthepaper.2OverviewofAccessibilityInthissection,wegiveabriefoverviewofaccessibilityinoperatingsystems,andpresentdenitionsofterminologiesusedinthispaper. 1Wediscoveredelevennewattacks,andwecoveranattackforSirithatwasreleasedinpublicasexploitationofaccessibilityinOS.2Disclosure:wereportedallvulnerabilitiesthatwefoundtotheOSvendors. Figure1:Generalarchitectureforimplementingaccessibilityfeatures.SupportinganaccessibilityfeaturecreatesnewpathsforI/Oonthesystem(twodottedlines),whileoriginalI/Ofrom/tohardwaredevices(e.g.,keyboard/mouseandscreen)isindicatedontherightside.2.1AccessibilityFeaturesIncompliancewiththeamendedRehabilitationAct,softwareven-dorshaveincorporatedvariousaccessibilityfeaturesintotheirsys-tems.Inthispaper,wedenecomputeraccessibility(a11y)featuresasnewI/Osubsystemsthatprovidealternativewaysforuserswithdisabilitiestointeractwiththesystem.Forexample,forvisuallyimpairedusers,text-to-speechbasedNarrator(onMSWindows),VoiceOver(onOSX),andTalkBack(onAndroid)provideanoutputsubsystemthatcommunicateswiththeuserthroughspeech.Forhearingimpairedusers,accessibilityfeatureslikecaptioningser-vicesturnthesystem'saudiooutputintovisualoutput.Similarly,somesystemscanalerttheuseraboutthepresenceofaudiooutputbyashingthescreen.Foruserswithmotordisabilities,traditionalmouse/keyboardbasedinputsystemsarereplacedbysystemsbasedonvoiceinput.Ingeneral,wecanseetheseaccessibilityfeaturesasimplementedwithinanOSarchitectureinFigure1.TherearealsoaccessibilityfeaturesthatusetraditionalI/Ode-vices(e.g.,thescreen,mouseandkeyboard),butmakethemeasierforuserswithdisabilitiestointeractwiththesystem.Examplesofsuchfeaturesinclude:1)MagnierinWindows,whichenlargescertainportionsofthescreen;2)HighContrastinWindows,whichprovideshighercontrastforeasydistinctionofuserinterfaces;and3)on-screenkeyboard,stickykeys,lterkeys,assistedpointing,andmousedouble-clickspeedadjusttoallowinputrequiringlessmovement.2.2AccessibilityLibrariesInadditiontopre-installedaccessibilityfeatures,mostOSvendorsprovidelibrariesforthirdpartiestoimplementtheirownaccessi-bilityfeatures.ThismakesitpossibletocreatenewalternativeI/OsubsystemsbasedonotherI/Odevices(e.g.abrailleterminal).Inthiscase,theassistivetechnologypartinFigure1isaprogramdevelopedbythirdparty.Examplesoftheselibrariesinclude1)UIAutomationinMicrosoftWindows,2)theaccessibilitytoolkit(ATK)andAssistiveTechnologyServiceProviderInterface(AT-SPI)inUbuntuLinux,3)AccessibilityServiceandrelatedclassesinAndroid,and4)the(public)NSAccessibilityand(private)UIAu-tomationframeworksiniOS. Figure4:RequiredsecuritychecksforanATasanewoutputsubsys-tem.Applicationisrequiredtodecidewhichinputcantransitthroughtheaccessibilitylibrary,thentheATreceivestheoutputtodeliverittotheuser.GrayedboxesindicatethechecksrequiredbyOSandtheapplication.ATcancontrol.Forexample,interactionrequestsfromuntrustedATtosecuritysensitiveprocessessuchassystemservicesandsystemsettingsshouldnotbeforwarded.Otherwise,privilegeescalationwouldbefeasible(A2).Inaddition,theaccesscontrolpolicyshouldbeconsistentwithotheraccesscontrolmechanismstopreventamaliciousATfromobtainingnewcapabilities(A1).Third,theOSshouldprovidetheexibilitytoallowanappli-cationtospecifyane-grainedsecuritypolicyonhowtohandleinteractionrequestsfromanAT.Morespecically,theOSshould1)allowtheapplicationtodistinguishinputfromrealhardwareandinputfromAT;and2)allowtheapplicationtosetitsowncallbackfunctionstohandleinputeventsfromAT.Moreimportantly,whennocustomizationisprovided,thedefaultsettingshouldalignwiththeplatform'sdefaultsecuritypolicy.Thesethreechecksarecomplementarytoeachotherforthefol-lowingreasons.First,forAT-likenaturallanguageuserinterfacesformotordisabledpeople,ithastobeabletocontrolallapplicationsandtheunderlyingsystem;theonlyviablecheckiswithintheATitself.Second,asnotallATsaretrustworthy,theOS-levelcheckisnecessarytopreventmaliciousATfromcompromisingthesystem.Third,OS-levelaccesscontrolsarenotawareofthecontextofeachnon-systemapplication,sotheapplicationlevelcheckprovidesthelastlineofdefenseforanapplicationtoprotectitselffrommaliciousATs(A1).Similarly,tosecurelyhandlealternativeoutputandpreventinfor-mationleakage(A3),twochecks(grayboxesinFigure4)shouldbeperformed.TheapplicationlevelcheckallowstheapplicationtospecifywhatinformationissensitivesoitwillnotbeavailabletoAT.Again,wemustemphasizethatwhennocustomizationisprovided,thedefaultsettingshouldalignwiththeplatform'ssecuritypolicy.TheOS-levelcheckpreventsuntrustedATsfromacquiringsensitiveinformationspecictothesystem.4SecurityEvaluationofA11yInthissection,werstdescribeourevaluationmethodology,andthenpresenttheresultsofthesecurityevaluationonmajorplatforms:MicrosoftWindows,UbuntuLinux,iOS,andAndroid.Thespecicversionsoftheevaluatedsystemsare:Windows8.1,Ubuntu13.10,iOS6andAndroid4.4ontheMotoX3. 3ForWindows,Ubuntu,andAndroid,wetestedthelatestreleaseversionasofNovember2013.Attacksstillworkforthecurrent4.1EvaluationMethodologyGivenanOSplatform,weevaluatethesecurityoftheaccessibilityfeaturesito ersasfollows:1.Westudiedtheavailabilityofthebuilt-inassistivetechnologiesandtheaccessibilitylibraryontheplatform.Forbuilt-inassistivetechnologies,wefocusedontheavailabilityofanaturallanguageuserinterfacebecauseitprovidesthemostpowerfulcontroloverthesystem.Fortheaccessibilitylibrary,wefocusedonwhetheranapplicationneedsspecialprivilegestousethelibrary;ifso,howsuchprivilegesaregranted.2.Usingourinputvalidationmodel(Figure3),weexaminedtheinputhandlingprocessoftheanalyzedplatform.Whenacheckismissingorawed,wetrytolaunchattacksexploitingthemissingorawedcheck.Specically,ifthebuilt-innaturallanguageuserinterfacelacksinputvalidationorifthevalidationcanbebypassed,wetrytoescalateourmalware'sprivilegethroughsyntheticvoice.IftheOS-levelcheckismissingandthereisasecuritymechanismthatrequiresuserconsent,wetrytoescalateourmalware'sprivilegebyspoongthemechanismwithsyntheticinput.IftheOS-levelcheckisnotmissing,weassesswhetheritsaccesscontrolpolicyisconsistentwithothersecuritymechanisms;ifnot,weevaluatewhatnewcapabilitiesbecomeavailable.Iftheapplicationlevelcheckismissingorawed,weexaminewhetheraccessibilitysupportprovidesusnewcapabilities.3.Usingouroutputvalidationmodel(Figure4),weexaminedtheoutputhandlingprocessoftheanalyzedplatform.IftheOS-levelcheckismissing,wetrytoreadtheUIstructureofotherappli-cations.Iftheapplicationlevelcheckismissing,weexaminewhethernewcapabilitiesbecomeavailable.Inparticular,sincemostofdisplayedinformationisavailablethroughscreenshots,wetrytostealapasswordbecauseitisusuallynotdisplayedinplaintext.Weassumeobtaininganyother(potentiallysensi-tive)informationasplaintextviaATisnoharderthanreadingapassword.4.2AvailabilityofAccessibilityFeaturesTable1summarizestheavailabilityofanaturallanguageuserinter-faceandaccessibilitylibrariesonthefourplatforms.Naturallan-guageuserinterfacesareavailableonallplatformsexceptUbuntu;accessibilitylibrariesareavailableonallstudiedplatforms4. Platform NaturalLanguageUserInterface AccessibilityLibraries Windows SpeechRecognition* UIAutomation Ubuntu None ATK,AT-SPI iOS Siri UIAutomation* Android TouchlessControl* AccessibilityService* Table1:Accessibilitylibrariesandnaturallanguageuserinterfaceoneachplatform.*indicatesthefeaturerequiresspecialsetup/privilege.Fornaturallanguageuserinterfaces,bothSpeechRecognitionandTouchlessControlfortheMotoX5requireinitialization(training) releaseversions.ForiOS,wetestediOS6.1.4,thelatestiOS6atthetimetheresearchwasperformed.4OniOS,thereisnoaccessibilitylibrary,buttheUIAutomationframeworkprovidesmostcapabilitiesthatwerequire.5ForthenaturallanguageuserinterfaceonAndroid,wetrytoanalyzeTouchlessControlwhichisonlyavailableontheMotoX,duetothelackofaprivilegednaturallanguageuserinterfaceinAndroidbydefault. Figure5:WorkowofprivilegeescalationattackwithWindowsSpeechRecognition. Figure6:Dialogthatpops-upwhenExplorer.exetriestocopyaletoasystemdirectory.ThedialogrunsatthesameMediumILasExplorer.exe.Thus,anyapplicationwithMediumILcansendasyn-theticclicktothe“Continue”button,andproceedwithwritingthele.applicationthroughCreateProcess().Sincemsconfig.exeisanapplicationforanadministratortomanagethesystemcongura-tion,itautomaticallyrunsatHighIL.Whilemalwarecannotsendinputeventstothisprocess(preventedbyUIPI),SpeechRecog-nitioncan.Afterlaunchingmsconfig.exe,themalwarecanusevoicecommandstolaunchacommandshellbychoosinganitemunderthetoolstabofmsconfig.exe.Thisisaccomplishedbyplayingapieceofsyntheticspeech“Tools,PageDown,CommandPrompt,Launch!”.OncethecommandshellthatinheritstheHighILfrommsconfig.exeislaunched,themalwarethensays“cd”toitsdirectory,saysitsownexecutablenameand“PressEnter”tobeexecutedwithadministrativeprivileges.Attack#2:privilegeescalationwithExplorer.exe.Explorer.exeisaspecialprocessinWindowsthathashigherprivilegethanitsrunningIL.UnlikeotherMediumILprocesses,Explorer.exehasthecapabilityofwritingtoHighILobjectssuchastheSystem32directory.AlthoughthiscapabilityisprotectedbyaUAC-likedia-log(Figure6),i.e.,Explorer.exeasksfortheuserconrmationbeforewritingtoasystemdirectoryofWindows,thedialogbelongstoExplorer.exeitself.Sincethisactionrequiresuserconsent,theapplicationshouldcheckwhethertheinputcomesfromtheuserorAT.However,thereisnosuchcheck.Asaresult,malwarecanoverwritelesinsystemdirectoriesbyclickingtheconrmationdialogthroughtheaccessibilitylibrary.Somesystemapplicationsinsystemdirectoriesareautomaticallyescalatedtotheadministrativeprivilegeatlaunch.OnWindows,whenaprocesstriestoloadaDLL,thedynamiclinkerrstlooksfortheDLLfromthelocaldirectorywheretheexecutableresides. Figure7:PasswordEyeontheGmailwebapplication,accessedwithInternetExplorer10.InWindows8and8.1,thisEyeisattachedtopasswordeldsnotonlyforwebapplications,butalsoregularapplica-tions.Byleft-clickingtheEye,theboxrevealsitsplaintextcontent.OncemalwareinjectsmaliciousDLLsintothedirectorycontainingtheseapplications,itcanobtaintheadministrativeprivilegewhentheapplicationsarerun,thusbypassingUAC.Anexampleofsuchanapplicationissysprep,whichwillloadCryptbase.DLLfromthelocaldirectory.BysendingsyntheticclickstoExplorer.exeandinjectingamaliciousCryptbase.DLL,malwarecanachieveprivilegeescalation.Attack#3:stealingpasswordsusingPasswordEyeandascreen-shot.OnWindows,passwordsareprotectedinseveralways.Theyarenotshownonthescreen;andevenwithrealuserinteractions,thecontentinapasswordboxcannotbecopiedtotheclipboard.Furthermore,aswillbedescribedindetailinSection§4.4,itisalsonotpossibletoretrievepasswordcontentdirectlythroughtheaccessibilitylibrary.However,thelackofinputvalidationonthepasswordboxUIcomponentopensupamethodofstealingtheplaintextofapassword.StartingwithWindows8,MicrosoftintroducedPasswordEyeasanewUIfeaturetogivevisualfeedbacktouserstocorrectatypoinapasswordinputbox(Figure7).This“Eye”appearswhenauserprovidesinputtoapasswordbox,andclickingitwillrevealtheplaintextofthepassword.Unfortunately,sincePasswordEyecannotdistinguishhardwareinputfromsyntheticinput,malwarecanclickitaslongasUIPIpermits.Again,sincemostapplicationsrunatthesameILasmalware,malwarecansendaleft-clickeventtorevealthecontentofthepassworddialog(Figure7),andcanextractitfromascreenshot.4.3.2UbuntuLinuxDesktopSinceUbuntudoesnothaveabuilt-innaturallanguageuserinter-face,weonlyconsidertheattacksenabledbymissingchecksintheOSoranapplication.ThemissingcheckattheOSlevelallowsmalwaretocontrolanyapplicationandthusbreaktheboundaryenforcedbyothersecuritymechanisms(attack#4).Themissingcheckattheapplicationleveldoesnotprovideadditionalcapabili-tiesbeyondthosealreadyprovidedbythemissingOSlevelcheck.Attack#4:bypassingthesecurityboundariesofUbuntu.SinceneithertheOSnorapplicationsauthenticateinput,malwarecansendsyntheticinputtoanyapplicationintheGUI,i.e.thecurrentXWindowdisplay.Thedisplayheredoesnotmeanthephysicaldisplay(i.e.,amonitorscreen)ofthedevice;rather,itreferstothelogicaldisplayspace(e.g.,:0.0)oftheXWindowServer.Inthissetting,thelackofsecuritychecksforinputbreakstwosecurityboundariesinUbuntu.TherstviolationisregardinguserID(UID)boundaries.RegardlessoftheUIDofthedisplayservice,alaunchedprocesswillrunwiththeUIDoftheuserwholaunchedit.Forexample,ifanon-rootuserrunsaGUIapplicationwithsudo(e.g.,sudogpartedoraGUIshellwithrootprivileges),the Figure10:AdministratorauthenticationdialogofGNOMEonUbuntu13.10.Itasksforthepasswordofthecurrentusertogainrootpermis-sions.AT-SPI.ThesecuritychecksattheOSlevelareincomplete.Forapasswordbox,thereexistsanAPIcall,gettextvalue(),ontheLinuxDesktopTestingProject(LDTP,awrapperoverAT-SPIandATK).Itthrowsa“NotImplemented”exceptionwhencalled,meaningthatreadingpasswordsthroughthisAPIisunavailable.However,AT-SPImissedsecuritychecksonacriticalaccessibilityfunctionofapasswordbox:copytext().AlthoughphysicallyorsyntheticallypressingCtrl-Cdoesnotcopythevalueofapass-wordbox,copytext()fromAT-SPIdoescopytheplaintextofapasswordtotheclipboard.Theclipboardthencanprovidetheplaintextcontentofapassword.Figure10showsasudodialogthatisvulnerabletothisattack.Oncethesudoer'spasswordisacquiredinthismanner,malwarecaneasilygainrootprivileges.4.4.3AndroidWhileAndroidprohibitsreadingofpasswordcontentfromitsac-cessibilityservice,thiscanbedisabledviauserpreferences.Inconjunctionwiththevulnerabilityofinputvalidation(attack#10),thisrestrictioncaneasilybebypassed.Attack#12:keyloggeronAndroid.AlthoughAndroidprovidesprotectionsforaccessingtheplaintextofapassword,incompleteprotectionsattheOS-levelleadtoavulnerability.OnceanappisenabledasanAT(seeAttack#10fordetail),theappcanchangeanysettingsonthedevicewithoutuserconsent.Androidprovidesanoptioncalled“Speakpasswords”initsaccessibilitysettings.Ifenabled,keystrokesonapasswordboxaredeliveredthroughthetext-to-speech(TTS)processor.WeregistermalwareasaTTSoutputapplication.Onceregistered,themalwarecanreceivepasswordcontentsviatheOS-levelaccessibilityservice.5DiscussionInthissection,weexplainhowaccessibilitylibrariesaremakingitpossibletoimplementourattacks,discussthelimitationsofourattacks,analyzetherootcausesofthevulnerabilities,andconsideropenproblemsforfuturework.5.1ComplexityofAccessibilityAttacksAswementionedinsection§2,accessibilitylibrariesprovidethreecapabilities:1)obtainingeventsrepresentingUIchange,2)provid-ingawayofprogrammaticallyprobing/accessingUIwidgets,and3)synthesizinginputstoUIwidgets.Withthesefunctionalities,anattackercancreatemalwarecapableofperformingsuccessfulattackswithadegreeofrelativeeasewhencomparedtoothernon-ATmethodsthatachievethesameends.Asanexample,wewilldescribehowthe“PasswordEye”attack(#3)canbeimplementedusingaccessibilitylibraries.Toachievethe“PasswordEye”attack,malwareneedsto:1)detectwhentheusertypesapassword,2)identifytheUI“eye”andclickonit,and3)lo-catethepasswordeldtograbitstextinascreenshot.Todeterminewhethertheuseristypingpassword,wecanusetherstcapabilityoftheaccessibilitylibrariestokeeptrackofwhichUIcomponentiscurrentlyfocused.Inparticular,ontheWindowsplatform,thiscanbeeasilyachievedbyregisteringaneventhandlerintheplat-form'saccessibilityframeworkthatreceivesthefocusedUIelementatanychangeoffocus.Afterbeinghandedafocusedelement,wecancheckwhethertheelementisapasswordboxwithan“eye”byassessingitspropertiesreportedbytheaccessibilitylibraries.Forex-ample,aTRUEvalueofisPasswordpropertyindicatesapasswordbox.Oncewedeterminethatthefocusedelementisapasswordbox,wecanusethesecondcapabilityoftheaccessibilitylibrariestogetthe“eye”button.Inparticular,sinceweknowtherelativepositionofthefocusedtextboxandthe“eye”button,wecanwalktheUIwidgettreeprovidedbytheaccessibilitylibraryandcalculatethepositionofthe“eye”.Then,wecanusethethirdcapabilitytoclickit.Finally,thehandletothefocusedpasswordboxweobtainedintherststepcanalsobeusedtoretrievethelocationoftheboxonscreen,andallowustograbtheactualpasswordtypedfromascreenshot.ApointworthnotinghereisthatdevelopingattacksusingaccessibilitylibrariesisverysimilartohowonemanipulatesDOM(DocumentObjectModel)objectsusingJavascriptinawebpage.OnemaypointoutthatthesameattackcanbeachievedontheWindowsplatformbysendingtraditionalWindowsMessages(suchasWM_CLICK),orusingtoolssuchasAutoIt.However,wearguethattheuseoftheaccessibilitylibrarygreatereaseandreliability.Inparticular,withouttherstcapabilityoftheaccessibilitylibraries,onemayneedtoconstantlyprobethecurrentstateofUIstodeter-mineiftheuseristypingapassword.Secondly,whileitmaybetrivialtouseahardcodedcoordinatetoclickthe“eye”buttoninatestingenvironmentsuchasAutoIt,thisstrategywillbeveryfragileinarealattack;factorssuchasvariationinscreensizeandresizing/-movingofthetargetwindowmaybreakthehardcodedapproachinarealattack.Usinghardcodedlocationstoextractapasswordfromscreenshotswillfaceasimilarissue.Eventhoughitmaybepossibletoreliablyimplementourattackswithoutaccessibilitylibraries,thisimplementationwouldbemorecomplexandrequiregreatere ortonthepartoftheauthor.5.2LimitationsoftheAttacksSinceattacksthroughaccessibilitylibrariesperformactionsoveruserinterfaces,theyhaveaninherentlimitationinthattheyarenotstealthy.Forexample,ifthetargetapplicationisrunningintheforegroundwhenanattackisunfolding,theusermayrecognizevisualcuesoftheattack,suchasbuttonpresses,openingofanewUIwindow,etc.Furthermore,attacksviavoicecommandsplaysounds,andarethusaudible;ortheyfailifthespeakeristurnedo .However,wearguethattheseattackscanbelaunchedinastealthyway.First,malwarecandetectwhethertheuserisusingthedeviceornot.Fordesktopmachines,thepresenceofausercanbedetectedbymonitoringphysicalkeystrokeormousemovement.MalwarecanexploitatimeperiodwhentheuserisabsenttolaunchUI-intensiveattacks.Ifnecessary,themalwarecanblankthescreenwhenlaunchingtheattack,becausescreensleepaftersomeperiodofnon-useisanaturalandexpectedbehaviorofthesystem.Formobiledevices,priorresearches[17,31,35]discussedhowtotracktheuser'sbehaviorusinganapponthedevice.Withthehelpofvarioussensors,suchasthecamera,faceproximitydetector,GPSlocation,accelerometer,etc.,malwarecandeterminewhentheuserisnotwatchingthescreen,awayfromthedevice,orwhenthedeviceisintheuser'spocket.Itcanthenlaunchanattackwithoutbeingexposed.Second,UIactionscanbedeliveredinthebackgroundforsomeplatforms.Thus,anattackcanbecarriedoutevenwhentheuserisactivelyusingthedevice.InWindows,onceahandletoaUIwidgetisobtainedwhileitisintheforeground,itcanstillbemanipulated whichwefeelisanacceptabletrade-o fortheextrasecurityagainstmisuseoftheaccessibilitylibrary.OursecondrecommendationistoprovidemechanismsforaUIdevelopertoaghowdi erentwidgetsintheirUIwillhandlevariousrequestsfromtheAT,ratherthanrequiringtheUIdevelopertohandlethistaskthemselves.Forexample,inmanyUIlibraries,adevelopercanagatexteldasapasswordeld,andtheunderlyinglogicoftheUIwillmakethecontentintheeldinvisibletoboththedisplayandtheATs.However,thisgenerallyappearstobetheonlyinstanceofsuchaag,anditonlyappliestotextelds.Webelievemoresuchagsshouldbeavailabletospecifyvariousa11yrelatedsecuritypolicies,andsuchagsshouldbemadeapplicabletovariouskindsofwidgets(e.g.attack#2and#3canbeeasilyeliminatedifasecurityagisapplicabletobuttons).Asfuturework,wewillstudywhatkindofa11yrelatedsecuritypoliciesUIdevelopersusuallyneedtospecify,andwhatlanguagefeaturesareneededforspecifyingsuchpolicyasattributesofwidgetsintheUI.Ournalrecommendationcanbeconsideredanewsecuritycom-ponentinthecurrenta11yarchitecture,andcansignicantlylimitthedamagecausedbyexploitationofa11y-relatedvulnerabilities.Weproposetoextendaccessibilitysupporttouser-drivenaccesscontrolmechanismslikeUACinWindowsorRemoteViewiniOS.Whilethisrecommendationmaynotbedirectlyderivedfromourrootcauseanalysis,webelieveitwillfundamentallyeliminatemanya11yrelatedsecurityissuesdiscussedinthispaper.Inparticular,OSvendorsshoulddevelopversionsofaccesscontrolmechanismstosupportvariousdisabilities.Forexample,forvisuallyimpairedusers,thesystemcanreadout(throughthespeaker)themessageseekingpermission,andhavetheuserconrmorabortbyclickingthe“F”or“J”buttononthekeyboard(whicharetactilelydi erentfromallotherkeysonthekeyboard),andfortheuserswholacknemotorskills,thepermissiongrantingcanbedrivenbyvoicerecognition.Wenotethatwhilethisapproachisnotgeneralenoughtosupporttheneedforalluserswithdi erentkindsofdisabilities,itwillsignicantlyimprovethesecurityforallusersthatarecovered.Furthermore,inthecaseofvoicerecognition,theintroductionofamechanismspecicallydesignedforseekingvocalpermissionmaysignicantlysimplifythetaskofauthenticatinguserinput(only“yes”or“no”needbeveried,ratherthanperforminggeneralvoicerecognition),andthusmovetheburdenofperformingvoicerecogni-tionfromtheATdevelopertotheOSvendor(whomayhavemoreresourcestoresearchanddevelopamechanismthatisrobustagainstattack#1and#9).Finally,weacknowledgethatouranalysisrequiressignicantmanuale ortandreverseengineeringworkandthusisnotexhaus-tive.Wewillleaveitasanopenproblemtodesignsystemsthatcanautomaticallynda11yrelatedvulnerabilities.Webelievethiswillbeachallengingproblemfortheseveralreasons.First,automaticallydetectinga11yfunctionsandanalyzingtheirrelatedvulnerabilitiesrequireswholesystemanalysis.Sinceana11yrequestisregardedasanI/Oevent,itisprocessedasynchronously.Asaresult,itisveryhardtondentrypoints.Thecomplicatedexecutionofa11ylogicextendstomanydi erentlow-levelmodules,whichusuallymakeuseofmany(function)pointers.ProprietaryOSsdonotprovidesourcecode,andsoresearcherscanonlyperformanalysiswiththecompiledbinary,whichmakesthetaskevenharder.Second,unlikegeneralprogrammingerrors,conrminga11yrelatedvulnerabilitiesrequiresadeepunderstandingofthesemanticsofanapplication,whichsignicantlylimitsthescalabilityofsuchanalysis.Wehopethatourworkcanmotivatefurtherstudiestowardthisdirection.6RelatedWorkAttacksonWindows.In2007,itwasreportedthatanattackercouldcontrolaWindowsVistamachinebyplayingsoundtoSpeechRecognition[28].However,sincetheattackcouldnotbypassUACandassumedSpeechRecognitionwasalreadyenabled,itwascon-sideredaminorbugatthattime.Comparedwiththisattack,ourattack(attack#1)doesnotrequireSpeechRecognitiontobeenabledbeforetheattack,andwecanbypassUAConWindows7through8.1(duetopolicychangesinUAC[26]).JustbeforethereleaseofWindows7,therewasaUACbypassattack[10]thatexploitedthespecialcapabilityofExplorer.exetowritetosystemdirectories.Inthisattack,amalwareprocesswillattachtoExplorer.exe,injectcode,andexploititscapabilitytowritetosystemdirectories.Ourattack#2followsthesamestrategy,butinsteadofusinglowlevelfunctionWriteProcessMemory()toinjectcodeintoExplorer.exe,weusedtheaccessibilitylibrarytosimplyclickthe“OK”button.AttacksoniOS.Recently,itwasreported[11]thatSiriiniOS7canbeexploitedtobypassthelockscreenandsendemail,SMS,postonTwitterandFacebook,makephonecalls,etc.Wereferredtothisattackasattack#5inthevulnerabilitysection.AlthoughtheaccessibilitylibraryisaprivateAPIthatisnotusablebyregularappdevelopers,thethreatisreal.Lastyear,anattack[33]showedthatitispossibletocircumventtheAppleAppStorereviewprocessbysuccessfullypublishinganAppStoreappthatinvokedprivateAPIcalls.AttacksonAndroid.InAndroid,therehavebeenmanyattacksonthepermissions[7,9,13,16,34]andprivateinformation[18,36]ofanappthatdemonstratedataleakagethroughAndroid'sIPCchannel.Toaddresstheseproblems,manymechanisms[6,12,16,20]havebeenproposed.Unfortunately,sincealloftheproposedmechanismswerefocusedontheocialIPCchannel,theyarenotabletopreventattacksthroughaccessibilitylibraries.Furthermore,ourattackscanstealthecapabilitiesandprivateinformationofotherapps.7ConclusionIncompliancewiththeamendmenttotheRehabilitationActof1973,softwarevendorshavebeencontinuouslyaddingaccessibilityfeaturestotheirOSs.Asthetechnologyadvances,accessibilityfeatureshavebecomecomplexenoughtocompriseacompleteI/Osubsystemonaplatform.Inthispaper,weperformedananalysisofthesecurityofaccessibilityfeaturesonfourpopularplatforms.Wediscoveredvulnerabilitiesthatledtotwelvepracticalattacksthatareenabledviaaccessibilityfeatures.Furtheranalysisshowsthattherootcauseoftheproblemisduetothedesignandimplementationofa11ysupportrequiringtrade-o sbetweencompatibility,usability,andsecurity.Weconcludewithproposingseveralrecommendationstoeithermaketheimplementationofallnecessarysecuritycheckseasier,ortoalleviatetheimpactofincompletechecks.AcknowledgmentsTheauthorswouldliketothanktheanonymousreviewersandourshepherd,TrentJaeger,fortheirhelpandfeedback,aswellasouroperationssta fortheirproofreadinge orts.Thismate-rialisbaseduponworksupportedinpartbytheNationalScienceFoundationunderGrantsNo.CNS-1017265,CNS-0831300,andCNS-1149051,bytheOceofNavalResearchunderGrantNo.N000140911042,bytheDepartmentofHomelandSecurityundercontractNo.N66001-12-C-0133,andbytheUnitedStatesAirForceunderContractNo.FA8650-10-C-7025.Anyopinions,ndings,andconclusionsorrecommendationsexpressedinthismaterialarethoseoftheauthorsanddonotnecessarilyreecttheviewsofthe