Java: Insecure Loading of Class in Android App without Package Signature Checking

[masterofnow]

Query PR

https://github.com/github/codeql/pull/14752

Language

Java

CVE(s) ID list

https://github.com/oversecured/ovaa

CWE

CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Report

1. What is the vulnerability? The vulnerability is when an Android app insecurely load a class and invoke the method in an Android package without checking the package signature but only rely on the package name.

2. How does the vulnerability work? Malicious app with the same package name can be installed in the victim device and causes "package namespace squatting". The vulnerable app would then load classes or code from the malicious app, potentially leading to arbitrary code execution.

3. What strategy do you use in your query to find the vulnerability? Check that the when createPackageContext() is called using a packageName, the same packageName has a dataflow from checkSignatures() called. Then, check that the context created from createPackageContext() is later used to invoke a method.

4. How have you reduced the number of false positives? By having 3 versions of the same potentially vulnerable code. a. One that calls createPackageContext() without signature checking. Make sure the QL detects the vulnerability. b. One that calls createPackageContext() with signature checking. Make sure the QL detects nothing. c. One that calls createPackageContext() in two methods in the same .java file, one checks the signature, the other do not. Make sure the QL only detects the vulnerable method and not the one without the vulnerability.

5. Other information? https://github.com/github/securitylab/issues/232 was also targetting https://github.com/oversecured/ovaa.

Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc).

• [ ] Yes
• [ ] No

Blog post link

No response

[sylwia-budzynska]

Hi @masterofnow 👋 Thank you for the submission. For your submission to go forward in the triaging process, your query should be able to detect a real CVE - OVAA is a deliberately vulnerable project, and unfortunately it can’t be accepted here. Let me know when you have found a CVE. See rule 4 in the rules. If you can, please send also a CodeQL database with that issue present, so I can test for it later in the process.

[masterofnow]

Hi @sylwia-budzynska,

Thank you for your clarification. Initially, I submitted the PR using a bug category in OVAA primarily because I saw https://github.com/github/securitylab/issues/232 was also doing it. My apology.

I looked around and found out that CVE-2015-6606 falls into the same category of vulnerability. I have since updated my query to cater for both CVE-2015-6606 and OVAA. Note that CVE-2015-6606 is placed into a different CWE as I initially categorized this PR, but I feel the current CWE-470 still make sense. Let me know otherwise.

Also note that at the moment, the PR only have .ql and .qhelp but no .java unit test file yet. I am not familiar on how to run the unit test hence didn't write it. I can add it later if it is needed.

How do I send the CodeQL database? Is there a specific place I can upload it to?

[sylwia-budzynska]

Thank you for the update @masterofnow . If the database is small enough, you could upload it in this issue. If it is too big, you could create a repository and upload it there, and then share the link to the repository.

If you haven’t done that yet, I suggest running this query with MRVA and a list of repositories focused on Android apps. The more (true positive) results your query finds, especially in popular open source projects, the more likely it will get a high bounty. If you do have a list with open source Android apps on GitHub that could be used with MRVA, feel free to share. If you come up with any ways to improve the query, feel free to make changes to the PR.

As for the testing the CodeQL queries, here’s the documentation about it, and here is a recent BB submission with CodeQL tests to serve as an example. You might also want to add good and bad code examples to the docs.

If you’d like to maximize payout for this or future submissions, here are a few general guidelines, that we might take into consideration when reviewing a submission.

• the vulnerability modeled in the submission is impactful
• the submission finds new true positive vulnerabilities
• the submission finds very few false positives
• the submission models widely-used frameworks/libraries
• code in the submission is easy to read and will be easy to maintain
• documentation is written clearly, highlighting the impact of the issue it finds and is written without grammatical or other errors. The good and bad code samples clearly show the vulnerability.
• the submission includes tests, change note etc.

Please note that these are guidelines, not rules. Since we have a lot of different types of submissions, the guidelines might vary for each submission.

[masterofnow]

Here are the database files. ovaa.tar.gz cve-2015-6066.tar.gz

I will keep you posted on the progress of MRVA and any update on the unit test.

[sylwia-budzynska]

To be clear, you don’t have to run MRVA as part of the bug bounty programme. It's just a suggestion, together with the bullet points. As for the query tests, there's no need to update me on them, but feel free to update them in your PR and chat with the CodeQL team member that will be reviewing your submission about it - they decide on tests.

[ghsecuritylab]

Your submission is now in status Query review.

For information, the evaluation workflow is the following: Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

[masterofnow]

Thanks for the info, @sylwia-budzynska.

[masterofnow]

Hi @sylwia-budzynska, any update on this issue? I have yet to receive any feedback on the PR. Thanks.

[sylwia-budzynska]

A review from the CodeQL team often comes after 3-4 weeks after SecLab review, and it's been a week since my review. I'll mention it to the CodeQL team this time, but it might happen that it still takes a few weeks. In the meantime, I encourage you to add/update your PR with the suggestions I mentioned before in this issue.

[ghsecuritylab]

Your submission is now in status Final decision.

For information, the evaluation workflow is the following: Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed

[xcorail]

Hello @masterofnow can you please provide a public email address, or send me privately an email address? Best regards

[masterofnow]

Hi @xcorail,

I have just sent you an email with the following random value: 81d76d2c942362520b5829cdf9a2a793cfd5340b821b27c423eeb653dc57ae0a

[xcorail]

Created Hackerone report 2309507 for bounty 541950 : [800] Java: Insecure Loading of Class in Android App without Package Signature Checking

[ghsecuritylab]

Your submission is now in status Closed.

For information, the evaluation workflow is the following: Initial triage > Test run > Results analysis > Query review > Final decision > Pay > Closed