Android binder security -

Android binder security -

is interprocess communication provided binder in android protected against man in middle attacks? there documentation provides info?

binder uses capability-based security model. each binder object represents capability; handing object process grants process access capability. perspective, prevent man in middle attacks not handing of import binder object man in middle. if process doesn't handed binder object, can not access in way.

regarding "cross-binder reference forgery" issue discussed in paper, if understanding specific scenario talking about, think addendum user space little weaker agree with. create error think of looking @ special c code written servicemanager. formally, consider c++ user space code (consisting in particular of parcel) beingness part of binder architecture. code in particular makes sure deal such attempts @ spoofing when phone call readbinder() , related methods.

i don't agree statement flaw kernel not ensuring integrity of data. way imagine defined standard typed info construction binder transactions, read , verify contents of parcel. puts much knowledge in kernel in opinion, , no real benefit. no matter how much set there, user space need kind of validation of incoming transaction ensure matches expectations. today done @ level of validating primitive info read operations on parcel (readbinder(), readstring16(), readint(), etc) written avoid attacks. pushing more validation kernel still require validation in user space info types correct, , have moved opportunities attacks (due bugs in code) user space kernel.

one final thing binder security is of import realize @ platform level there of import security model implemented on top of binder infrastructure. permission/uid-based system, services can check uid of incoming calls verify them against allowed permissions.

this security model has spoofing vulnerability must deal with. typical scenario application receiving ibinder activity manager service (since can that). api of activity manager service based on checking uid of incoming calls determine allowed -- illustration if phone call bindservice() made, check see if uid has permission bind given service. malicious app seek play games here handing activity manager ibinder scheme service, illustration iwindow window manager. if knows transactions sec scheme service make, set things makes phone call thinks resizewindow() ends becoming phone call bindservice() when comes set in activity manager (if 2 calls mapped same transaction id).

this vulnerability exists because binder scheme not typed in way, "method" calls transactions beingness sent integer transaction code , info buffer.

to protect against this, user space typed interfaces generated aidl set @ start of transaction buffer name of interface intending call, , receiving code of transaction checks interface name @ front end of buffer ensure matches own interace. way spoofer in scenario above caught when activity manager sees has incoming phone call interface window.

anyway, practical utilize android developers, uid-based security relevant core binder capability model. in cases enforce security restricting processes access binder. illustration how there ibinder representing each activity, scheme process , process running activity share.

in other cases , ibinder object shared interested processes, enforce security @ point of phone call based on uid. if using aidl supply standard implementation of such interfaces, own implementation of such security can done based on meaning want apply uids. example, utilize standard facility associated permissions uids , inquire bundle manager if incoming uid has permission.

android security binder