search

XilinJia / Podcini

Open source podcast player for Android in Kotlin with androidx.media3
GNU General Public License v3.0
124 stars 5 forks source link

cleartext traffic #3

Closed IzzySoft closed 3 weeks ago

IzzySoft commented 4 months ago

Checklist

App version

4.0.1

Where did you get the app from

Other

Android version

n/a

Device model

n/a

First occurred

n/a

Steps to reproduce

n/a

Expected behaviour

No usesCleartextTraffic

Current behaviour

Your app declares usesCleartextTraffic. Can you please clarify which cleartext connections are used and what for? Thanks in advance!

Btw: my scanner also reports:

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

This can easily be avoided:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

For some background: that BLOB is supposed to be just a binary representation of your app's dependency tree. But as it's encrypted with a public key belonging to Google, only Google can read it – and nobody else can even verify what it really contains.

Logs

android:usesCleartextTraffic="true" in AndroidManifest.xml

XilinJia commented 4 months ago

This setting was inherited from the forked project. I haven't looked into it, but presume it's set for the case where some podcast servers don't accept encrypted connections. Will check about it later.

IzzySoft commented 4 months ago

Thanks! Waiting for your findings then.

IzzySoft commented 4 months ago

Any news, @XilinJia? I get that warning with each new release here :wink:

XilinJia commented 4 months ago

regarding usesCleartextTraffic, sorry I haven't got a chance to check it. Guess it would require me to verify if all podcast servers accept encrypted connections, which is not a simple task. Perhaps you can explain why it matters much to you. I can understand it's critical for an email or personal messaging app, but for podcast player?

Regarding the SigningBlock blobs issue, I'm not sure where it's from and whether I should simply exclude all dependency metadata, which seems like not a good thing to do. Did you see it on the "play" apk?

IzzySoft commented 4 months ago

regarding usesCleartextTraffic

It's easy subject to MITM and thus a security question. As long as it's clear to those using it, it might not be a huge issue (think eg of a music player accessing your local library in the LAN). But in other cases it might be, and MITM could be used to inject malicious content.

So if there'd be a warning shown when a non-secured connection is encountered (eg. "did you forget the s with https?"), with some link to more detailed explanation, I'd simply add that as description for the flag to make it transparent, and that would be OK.

Regarding the SigningBlock blobs issue

The problem is not the metadata. It's more that this is an opaque blob: nobody except Google (to whose key this was encrypted) can really tell what's inside. And you can hide almost anything in those blobs, so they better not exist. What use they are even if nobody can read them? If you want that metadata for playstore, you could leave it in the AABs you upload there (leave out the includeInBundle = false) and just keep it out of the APKs.

Did you see it on the "play" apk?

What exactly is the difference between the two? Ah, that :scream:

Offending libs:
---------------
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Google Cast (/com/google/android/gms/cast): NonFreeComp
* Google Mobile Services (/com/google/android/gms): NonFreeComp
* Google Play Core (/com/google/android/play/core): NonFreeNet,NonFreeComp
* Firebase (/com/google/firebase): NonFreeNet,NonFreeComp
* fyydlin (/de/mfietz/fyydlin): NonFreeNet

6 offenders.

Dangerous flags:
----------------
* usesCleartextTraffic

Permissions:
------------
* android.permission.INTERNET
* android.permission.POST_NOTIFICATIONS
* android.permission.WRITE_EXTERNAL_STORAGE
* android.permission.WAKE_LOCK
* android.permission.ACCESS_NETWORK_STATE
* android.permission.ACCESS_WIFI_STATE
* android.permission.RECEIVE_BOOT_COMPLETED
* android.permission.FOREGROUND_SERVICE
* android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK
* android.permission.BLUETOOTH
* android.permission.VIBRATE
* ac.mdiq.podcini.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
* android.permission.READ_EXTERNAL_STORAGE*

SigningBlock blobs:
-------------------
0x504b4453 (DEPENDENCY_INFO_BLOCK; GOOGLE)

So: yes, there too. It's in all APKs by default unless you explicitly turn it off these days. As Google thinks it's the only "valid source of apps". If it would be for the "general good" it would not be encrypted with their key, but rather signed with it – so everyone could plainly see it but nobody could tamper it without breaking the seal. But they decided to encrypt it, i.e. to hide it from everyone but themselves. This IMHO is what's "not a good thing to do". Sharing those details transparently is good. But hiding things in encrypted blobs (like here) is not.

GitHubQueenn commented 4 months ago

Btw: my scanner also reports:

Just curious: what scanner are you using? Seems interesting.

IzzySoft commented 4 months ago

My own. Actually, above output is a combined one, but you can find all its pieces in my repo's GitLab repo. Basic instructions are in an article which also links to the source: Identify modules in apps. Library signatures are regularly "extended" by new ones, you can find some statistics here.

GitHubQueenn commented 4 months ago

My own. Actually, above output is a combined one, but you can find all its pieces in my repo's GitLab repo. Basic instructions are in an article which also links to the source: Identify modules in apps. Library signatures are regularly "extended" by new ones, you can find some statistics here.

So basically that software APKTools? Very cool.

XilinJia commented 3 months ago

I tested on Adnroid 14 with usesCleartextTraffic removed from manifest file, connection to some http sites appears working. It seems there aren't many http only podcast servers now, but this is only from my visual inspection. I plan to keep it off in 4.4.1 and see if users would report issues.

IzzySoft commented 3 months ago

OK, thanks! Just let me know then should it be needed.