It seems common (although bad practice) for receiving components (whether activity, service, or receiver) to not check the action string before acting on a received intent.
Sometimes this leads to security vulnerabilities - for instance, a broadcast receiver declaring an intent-filter for a protected broadcast action (protected broadcasts can only be sent by the system, not by other apps) but not checking the action string to make sure it matches the protected broadcast action value - allowing malicious apps to send a different (non-protected) action string and still trigger the receiver. Reference: section 3.2.1 of http://www.cs.berkeley.edu/~afelt/intentsecurity-mobisys.pdf In the case of this Intent MAC policy, it means that a malicious app could stuff android.intent.action.MAIN / android.intent.category.LAUNCHER in the intent and the filter will always allow the intent to be sent to any receiving component - which might not check the action string first before acting upon the intent. I'm not sure that it makes sense for Intent MAC to assume that receiving components will always be written correctly to check the action string. I sent these comments to the list on January 4: Policies that do not specify a destination (allow intents to be sent to any destination) seem dangerous (unless the only allowed sources are system apps). For example, the policy allowing android.intent.action.MAIN / android.intent.category.LAUNCHER to be sent from anywhere to anywhere (I think a previous version of the policy only allowed it to be sent from the Launcher app?), or the policy allowing android.media.action.IMAGE_CAPTURE or VIDEO_CAPTURE to be sent to anywhere (from any app with type "camera_perm" or "video_perm"). A malicious app can stuff one of those into an Intent then send it to any component that acts without first checking the action string. >-----Original Message----- >From: [email protected] [mailto:owner-seandroid- >[email protected]] On Behalf Of rpcraig >Sent: Wednesday, July 17, 2013 1:35 PM >To: Richard Haines >Cc: seandroid >Subject: Re: Intent_MAC - Possible patch for intent_mac.xml > >On 07/17/2013 12:30 PM, Richard Haines wrote: >> I have a pair of simple apps: one provides a service (installed as a >> 'platform' >> app) and the other is the client (running as untrusted_app). However they >are >> not related (i.e. they are signed differently), but the client knows the >> startIntent.setClassName. The client sends an intent to start the service. >> >> I did not expect the service to start with the default intent_mac.xml and >> mmac_types.xml files, however it did. >> >> After some digging I found that it was allowed because of this entry in the >> intent_mac.xml file: >> >> <intent> >> <filter> >> <action name="android.intent.action.MAIN"/> >> <category name="android.intent.category.LAUNCHER"/> >> </filter> >> <!-- Allow all apps to send this intent --> >> <allow name="find_main_activities"/> >> </intent> >> >> This does not seem that secure, so I've patched the file with the attached >> patch. This allows AOSP apps to send the intent, but not others. I then >> added entries in intent_mac and mmac_types to allow my apps to >communicate. >> This seems a more secure solution. >> >> Richard > >What if your example platform app exposes a service that intends to >allow anyone to use? > -- This message was distributed to subscribers of the seandroid-list mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe seandroid-list" without quotes as the message.
