Skip to content

Java: Add query for Improper Verification of Intent by Broadcast Receiver (CWE-925) #8669

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Jun 29, 2022

Conversation

joefarebrother
Copy link
Contributor

No description provided.

Copy link

@github-advanced-security github-advanced-security bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found 1 vulnerability.

@joefarebrother joefarebrother marked this pull request as ready for review April 27, 2022 15:32
@joefarebrother joefarebrother requested a review from a team as a code owner April 27, 2022 15:32
Copy link
Contributor

@atorralba atorralba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good looking query! Good job including the dynamically declared receivers too, I'm eager to see what this catches when run at scale.

I added some inline comments.

@atorralba
Copy link
Contributor

This is mostly looking good to me. I think we need FP ratio and performance evaluations before merging though.

@atorralba
Copy link
Contributor

After experimenting a little with real world results, it seems that this vulnerability cannot be exploited through dynamically registered receivers (i.e. using Context.registerReceiver), because for this attack you need explicit Intents (to avoid the requirement of using a privileged action), but dynamically registered receivers cannot be targeted by explicit Intents. This article explains it in detail: https://onemikro2nd.blogspot.com/2013/09/darker-corners-of-android.html

So, I think we should restrict the query to only check statically registered receivers (i.e. through the Android manifest). I guess we could also handle dynamically registered receivers that have a filter for both a privileged action and an unprivileged action, but I'd say this is a pretty rare case and the chances of the receiver actually doing something sensitive would drop significantly. So I'll leave up to you to decide whether you want to handle that case — otherwise, we should just remove everything related to registerReceiver from this query.

@atorralba atorralba added the ready-for-doc-review This PR requires and is ready for review from the GitHub docs team. label Jun 2, 2022
@mchammer01 mchammer01 self-requested a review June 6, 2022 09:25
Copy link
Contributor

@mchammer01 mchammer01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joefarebrother 👋🏻 - this LGTM, I've made a few comments and suggestions for your consideration.
Would be great if you could correct the typo, and reword the query description. Hope this helps 🙂

@@ -0,0 +1,19 @@
/**
* @name Improper Verification of Intent by Broadcast Receiver
* @description The Android application uses a Broadcast Receiver that receives an Intent but does not properly verify that the Intent came from an authorized source.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here, unless you absolutely need to use capitalization (like in Android).
Also, this is not the preferred syntax for a description ("Syntax X causes behavior Y."). Could you reword and remove the capitalization?

<overview>
<p>
When an android application uses a <code>BroadcastReciever</code> to receive intents,
it is also able to receive explicit intents that are sent directly to it, regardless of its filter.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does the its pronoun refer to here, the app or the BroadcastReceiver (sorry, not a developer)?

Copy link
Contributor Author

@joefarebrother joefarebrother Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It refers to the BroadcastReceiver


Certain intent actions are only able to be sent by the operating system, not third-party applications.
However, a <code>BroadcastReceiver</code> that is registered to receive system intents is still able to receive
other intents from a third-party application, so it should check that the intent received has the expected action.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not required?

Suggested change
other intents from a third-party application, so it should check that the intent received has the expected action.
intents from a third-party application, so it should check that the intent received has the expected action.

@atorralba atorralba merged commit 12fa696 into github:main Jun 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Java ready-for-doc-review This PR requires and is ready for review from the GitHub docs team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants