Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

False Negative: ImplicitPendingIntents.ql misses mutable implicit PendingIntents once they are stored, enriched, or sent through slightly noisier code paths.

Offen
#21,548 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
java
Bereich
mobile-dev, security

Rechercherichtung

Beginne mit Security/CWE/CWE-927/ImplicitPendingIntents.ql und den betroffenen Beispielen PosCase1.java, PosCase2.java und PosCase3.java. Reproduziere die False Negatives und verfolge nach, wie parcelable writes, die Speicherung von Feldern und array reads den Ablauf von der Konstruktion bis zum Senden beeinflussen; fertig ist es, wenn diese veränderlichen impliziten PendingIntents, die an nicht spezifizierte Empfänger gesendet werden, erkannt werden.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

False Negative: ImplicitPendingIntents.ql misses mutable implicit PendingIntents once they are stored, enriched, or sent through slightly noisier code paths.

Version
codeql 2.24.3

Checker

  • Checker id: Security/CWE/CWE-927/ImplicitPendingIntents.ql
  • Checker description: This checker detects when an implicit Intent is created and then flows into a PendingIntent that is sent to an unspecified third party.

Description of the false negative

These cases still create an implicit Intent, wrap it in a mutable PendingIntent, and then send that PendingIntent to an unspecified recipient. The extra parcelable write, field store, or unrelated array read does not change the security outcome.

Affected test cases

PosCase1.java

The intent remains implicit when it is wrapped in the PendingIntent and sent onward. The extra statements do not make it safe.

// Implicit Intent with mutable PendingIntent sent to third party, including allowed implicit read of parcelable extra, should be flagged as unsafe.
package scensct.core.pos;

import android.app.PendingIntent;
import android.content.Context;
import android.content.Intent;
import android.os.Parcelable;

public class PosCase1 {
    public void sendPendingIntentToThirdParty(Context context, Parcelable extraData) {
        // Implicit Intent creation
        Intent implicitIntent = new Intent("com.example.ACTION_TRIGGER");
        // Allowed implicit read of parcelable extra (policy allows reading parcelable extras)
        implicitIntent.putExtra("key", extraData);
        // Create mutable PendingIntent from implicit Intent
        PendingIntent pending = PendingIntent.getActivity(
            context,
            0,
            implicitIntent,
            PendingIntent.FLAG_MUTABLE
        );
        // Send to unspecified third party via PendingIntent.send()
        try {
            pending.send();
        } catch (PendingIntent.CanceledException e) {
            // Handle exception
        }
    }
}
PosCase2.java

This still creates a mutable implicit PendingIntent for an unspecified recipient. The issue is unchanged.

// Implicit Intent with mutable PendingIntent sent to third party, including implicit read of PendingIntent field, should be flagged as unsafe.
package scensct.core.pos;

import android.app.PendingIntent;
import android.content.Context;
import android.content.Intent;

public class PosCase2 {
    static class Container {
        PendingIntent pendingIntentField;
    }
    
    public void sendPendingIntentToThirdParty(Context context, Container container) {
        // Implicit Intent creation
        Intent implicitIntent = new Intent("com.example.ACTION_TRIGGER");
        // Create mutable PendingIntent from implicit Intent
        PendingIntent pending = PendingIntent.getActivity(
            context,
            0,
            implicitIntent,
            PendingIntent.FLAG_MUTABLE
        );
        // Implicit read of PendingIntent field (reading container.pendingIntentField)
        container.pendingIntentField = pending;
        // Send to unspecified third party via PendingIntent.send()
        try {
            container.pendingIntentField.send();
        } catch (PendingIntent.CanceledException e) {
            // Handle exception
        }
    }
}
PosCase3.java

The added statements are incidental. The important part is that the implicit intent still flows into a third-party PendingIntent.

// Implicit Intent with mutable PendingIntent sent to third party, including implicit read of Intent array, should be flagged as unsafe.
package scensct.core.pos;

import android.app.PendingIntent;
import android.content.Context;
import android.content.Intent;

public class PosCase3 {
    public void sendPendingIntentToThirdParty(Context context, Intent[] intentArray, int index) {
        // Implicit Intent creation
        Intent implicitIntent = new Intent("com.example.ACTION_TRIGGER");
        // Create mutable PendingIntent from implicit Intent
        PendingIntent pending = PendingIntent.getActivity(
            context,
            0,
            implicitIntent,
            PendingIntent.FLAG_MUTABLE
        );
        // Implicit read of Intent array (accessing intentArray[index])
        Intent retrievedIntent = intentArray[index];
        // Send to unspecified third party via PendingIntent.send()
        try {
            pending.send();
        } catch (PendingIntent.CanceledException e) {
            // Handle exception
        }
    }
}

Cause analysis

The query appears too dependent on a direct, linear construction-to-send pattern. Once the PendingIntent is written to a field, accompanied by another benign read, or the Intent is slightly enriched before wrapping, the result disappears.

That is too brittle for Security/CWE/CWE-927/ImplicitPendingIntents.ql. Real Android code rarely keeps these flows in a single minimal statement sequence.

References

None known.

Vorherrschende Sprache
CodeQL
Sterne
10.1k
Forks
2.1k
Ø Merge
2 T. 16 Std.
Gemergte PRs (30 T.)
143

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/codeql

Alle Issues in github/codeql

Ähnliche Issues

Weitere Issues zu Mobile Dev

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.