PrivSec-dev/privsec.dev
1
0
Fork 0
mirror of https://github.com/PrivSec-dev/privsec.dev synced 2025-02-20 18:31:35 -05:00
Code

Reword paragraph for clarity

Browse Source 
Signed-off-by: friendly-rabbit-35 <169707731+friendly-rabbit-35@users.noreply.github.com>
This commit is contained in:
friendly-rabbit-35 2024-05-20 18:57:40 +00:00 committed by Friendly Rabbit
parent 166b2cf97a
commit 1278ddaa51
1 changed files with 3 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
content/posts/android/F-Droid Security Issues.md
View File

@ -87,7 +87,7 @@ Furthermore, F-Droid **[doesn't enforce a minimum target SDK](https://gitlab.com
- Since August 2023, the Play Store requires new apps to target at least API level 33 (Android 13), and existing apps must target Android 13 or higher for updates to be submitted.
While it may seem bothersome, it's necessary to keep the **app ecosystem modern and healthy**. Here, F-Droid sends the wrong message to developers (and even users) because they should care about it, and this is why many of us think it may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 "Ice Cream Sandwich". Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.
Keeping the **app ecosystem modern and healthy** is necessary, though it may seem bothersome. As shown above, F-Droid's lack of enforcement on this front sends the wrong message to developers (and even users). They should care about an modern and healthy app ecosystem, and this is why many of us think F-Droid's [relegation of this upkeep](https://gitlab.com/fdroid/fdroiddata/-/issues/2210#note_440967209) to individual app developers may be even harmful to the FOSS ecosystem. Backward compatibility is often the enemy of security, and while there's a middle-ground for convenience and obsolescence, it shouldn't be exaggerated. As a result of this philosophy, the main repository of F-Droid is filled with obsolete apps from another era, just for these apps to be able to run on the more than ten years old Android 4.0 "Ice Cream Sandwich". Let's not make the same mistake as the desktop platforms: instead, complain to your vendors for selling devices with no decent OS/firmware support.
There is little practical reason for developers not to increase the target SDK version (`targetSdkVersion`) with each Android release. This attribute matches the version of the platform an app is targeting, and allows access to modern improvements, rules and features on a modern OS. An app can still ensure backwards compatibility in such a way that it can run on older platforms: the `minSdkVersion` attribute informs the system about the minimum API level required for the application to run. Setting it too low isn't practical though, because this requires having a lot of fallback code (most of which is handled by common libraries) and separate code paths.
@ -104,8 +104,7 @@ There is indeed a serious security issue with the OS first-party source feature
On that note, it is also worth noting that the repository metadata format for F-Droid isn't properly signed as it lacks whole-file signing and key rotation. [Their index v1](https://f-droid.org/2021/02/05/apis-for-all-the-things.html#the-repo-index) format [uses JAR signing](https://gitlab.com/fdroid/fdroidserver/-/blob/d70e5c2cd92eb1924caf51a1f88202749956038f/fdroidserver/signindex.py#L40) with `jarsigner`, which has serious security flaws. F-Droid added their [index v2](https://f-droid.org/docs/All_our_APIs/#the-repo-index) format with [support for `apksigner`](https://gitlab.com/fdroid/fdroidserver/-/commit/3182b77d180b2313f4fdb101af96c035380abfd7#e915676f3ed7e51adef7ee3d1eaa0ef7be386a84) in May 2022, but this just seems to be an over-engineered and flawed approach since better suited tools such as `signify` could be used to sign the metadata JSON.
As a matter of fact, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the aforementioned third-party client [Neo-Store](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29.
*Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates, but the issues with the privileged extension when installing apps through F-Droid still remain.*
As a matter of fact, the [new unattended update API](https://developer.android.com/reference/android/Manifest.permission#UPDATE_PACKAGES_WITHOUT_USER_ACTION) added in API level 31 (Android 12) that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid "as is". It should be mentioned that the aforementioned third-party client [Neo-Store](https://github.com/Iamlooker/Droid-ify/issues/20) supports this API, although the underlying issues about the F-Droid infrastructure largely remain. Indeed, this secure API allowing for unprivileged unattended updates requires not only the app repository client to target API level 31, but also the apps to be updated to target at least API level 29. *Update: since version 1.19.0, both the official F-Droid client and F-Droid Basic support unprivileged unattended updates on Android 12 or later, but the issues with the privileged extension when installing apps through F-Droid still remain.*
F-Droid's official client also lacks **TLS certificate pinning**. Certificate pinning is a way for apps to increase the security of their connection to services [by providing a set of public key hashes](https://developer.android.com/training/articles/security-config#CertificatePinning) of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (*man-in-the-middle* attack) could be possible and lead to various security issues, considering you're trusting an app to deliver you other apps.
@ -162,8 +161,7 @@ In modern Android, the background restriction toggle is what really provides the
Another example to illustrate the shortcomings of this approach would be the `QUERY_ALL_PACKAGES` low-level permission, which is referred to in F-Droid as the *query all packages* permission that "allows an app to see all installed packages". While this description is somewhat correct, it can also be misleading: apps do not need `QUERY_ALL_PACKAGES` to list other apps within the same user profile. Even without this permission, some apps are visible automatically (visibility is restricted by default [since Android 11](https://developer.android.com/training/package-visibility)). If an app needs more visibility, it will declare a `<queries>` element in its manifest file. In other words, `QUERY_ALL_PACKAGES` is only one way to achieve visibility. Again, this goes to show how low-level manifest permissions are not intended to be interpreted as high-level permissions that the user should fully comprehend.
The Play Store for instance conveys the permissions in a far less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by tapping "About this app" then "App permissions - See more" at the bottom of the page. The Play Store will inform the user that the app may request access to the following permissions; this kind of wording is more important than it seems.
*Update: since July 2022, the Play Store doesn't offer a way to display low-level permissions anymore.*
The Play Store for instance conveys the permissions in a far less misleading way: the main low-level permissions are first grouped in their high-level user-facing toggles, and the rest is shown under "Other". This permission list can only be accessed by tapping "About this app" then "App permissions - See more" at the bottom of the page. The Play Store will inform the user that the app may request access to the following permissions; this kind of wording is more important than it seems. *Update: since July 2022, the Play Store doesn't offer a way to display low-level permissions anymore.*
Moreover, [the Play Store restricts the use of highly invasive permissions](https://support.google.com/googleplay/android-developer/answer/9888170) such as `MANAGE_EXTERNAL_STORAGE`, which allows apps to opt out of scoped storage if they can't work with [more privacy friendly approaches](https://developer.android.com/guide/topics/providers/document-provider) (like a file explorer). Apps that can't justify their use of this permission (which again has to be granted dynamically) may be removed from Play Store. This is where an app repository can actually shine, particularly with a review process to protect end users from installing poorly made apps that might compromise their privacy. Not that it matters much if these apps target very old API levels that are inclined to require invasive permissions in the first place...