The second full security audit of F-Droid is complete. We are satisfied with the results, which confirmed again that the core security model and standard operations are solid. The audit pointed out issues in the core build process where we currently rely on manual review by trusted contributors to protect us. This audit also did show that we still have work to do to achieve our goal of keeping the Android client secure even when connected to a malicious server, for example, if an untrusted repository is manually added that was created by its operator to exploit. The full audit report is available: report_otf_fdroid.pdf (cached copy).
The audit was conducted by Radically Open Security, which is a natural partner for F-Droid since they share a focus on free software and open processes. Thanks to Open Tech Fund for finding the auditor and covering the costs of hiring them.
For more information about F-Droid’s security practices, see the documentation about the Security Model.
Reducing trust requirements
One key part of this audit was to push us further into reducing the level of trust required of the various pieces and participants in all the processes in F-Droid. Client/server systems are usually built around the assumption that the server operator is fully trusted. There are many trusted contributors working on F-Droid, and the people working on the core parts have a long and good track record. Nevertheless, it is very valuable to have a system that does not require trusting people and their computers. We aim to push all pieces of the F-Droid ecosystem to work according to the principle of least privilege.
New apps and updates are submitted to fdroiddata via merge request and git commits. Those changes are then stored forever in the git history. In the past, the code trusted everything in fdroiddata, since the commits are reviewed by humans for any malicious bits. This model has a very good track record in F-Droid as well as many other projects developed in the open by many people. Debian is a great example of this, since almost a thousand Debian Developers have commit privileges which could give them root on every machine running Debian.
This audit helped us ask the question: what kind privileges can be restricted or removed without changing the way contributors work? It also caught a number of issues where the code trusted the inputs from fdroiddata, where it had been committed and reviewed by humans, but that could then point to other code which could contain the exploits.
Reducing the trust given to various pieces reduces the stresses of contributing, and allows us as a community to open more things up to all sorts of contributors. If a contributor feels that their review is the last line of defence against exploiting F-Droid, that adds a lot of stress to the review.
There were no issues found in the Privileged Extension code or the interaction between F-Droid client and Privileged Extension.
- 4.1.19 OTF-019 — Potential SQL Injection
right now, repos are trusted inputs verified by signatures. This kind of finding helps us make it so less trust is required when using third party repos
- 4.1.26 OTF-026 — (fdroid Client) Insecure Implementation of SSL
This finding is labeling a standard practice in Android as insecure: “It is possible to install an SSL certificate on a device and run the application to capture its traffic on the proxy.” Android does not make it easy to accidentally include a certificate on the device, and it also puts up a constant notification when one is in place. We believe that following this recommendation would not noticeably improve real world security. It would eliminate legitimate use cases of installing a certificate on the device to inspect the traffic. For example: company firewalls that must inspect traffic to comply with regulations; or, auditing real world traffic of F-Droid during normal operation.
This could only be exploited to change the URL that is shown in the TOFU prompt to the user. The user is responsible for confirming what is listed in that prompt. It should be fixed, but does not seem urgent. It will be included when we overhaul the whole “App Repo” process.
- 4.1.23 OTF-023 — (fdroidclient) App Is Signed With SHA1withRSA, Known to Have Collision Issues
- 4.1.27 OTF-027 — (Privilege Extension) Mobile application package signed with weak algorithm SHA1withRSA
This is an issue in Android itself. If an APK is signed with SHA256, that APK will not work on Android < 4.3. Using a larger RSA signing key would also be ideal. But since migrating signing keys is not supported in Android, it would be a very difficult project. F-Droid includes other layers of protection for validating APKs, including GPG signatures on APKs as well as the whole secure F-Droid distribution mechanism.
The HTTPS pinning mechanism could definitely be improved. Since HTTPS pinning is not essential to secure operation, it has never been a high priority. The integrity of the files server remains protected by the signature on the index files. For f-droid.org and the Guardian Project repo, the keys to check those signatures are built into the client.
- 4.1.9 OTF-009 — Applicatioin uses TrustOnFirstUse (TOFU) Usage unverified signing certificate
- 4.1.10 OTF-010 — (fdroid Client) Exploiting “Nearby Swap” Feature to Show Malicious Prompt to Users or Redirect to Malicious Sites
- 4.1.17 OTF-017 — Use of Insecure Communication Mechanism - BluetoothClient.java
- 4.1.18 OTF-018 — Use of Insecure Communication Mechanism - BluetoothServer.java
- 4.1.25 OTF-025 — (fdroid Client) Snooping in Between Clients in “Nearby Swap”
4.1.10 OTF-010 was a serious issue that was fixed as soon as it was found, thanks to Radically Open Security’s open audit process. It made it possible to put up phishing prompts via the swap process, but could only be exploited from the same network that the target device is on.
The security of the nearby swap is built largely on the limited scope of attacks, since it works only via Bluetooth or via local Wi-Fi restricted to the current subnet. It is also only active for a very limited time, while the user is directly using it. Then, for file integrity, the index signing key is trusted on the first use, then all files are verified against the verified index. While the security of the process can definitely be improved, it was designed to replace other much less secure methods that are widespread.
Ideally, all Bluetooth connections would use the native Bluetooth encryption and all IP connections would use HTTPS. The usability issues related to adding support for those would probably make the nearby/swap feature almost useless without a very substantial chunk of work.
Moving towards least privilege
- 4.1.4 OTF-004 — Infoleak in Fdroidserver Checkupdates.py
- 4.1.5 OTF-005 — Code Injection in Fdroidserver Checkupdates Through Eval’ed User Supplied Data
- 4.1.6 OTF-006 — Code Injection Via Malicious Appid in Fdroidserver Build.py
- 4.1.34 OTF-034 — Maliciously Crafted Appid Code Injection in Fdroidserver Build.py
The build metadata files are used to describe an app and it’s build
process. They are usually created by trusted parties (e.g. the person
running the repo) or reviewed via merge requests. These findings would only
have caused problems for repos that included metadata files from untrusted
sources without reviewing them. For f-droid.org, the metadata files can
only be downloaded to the production servers via git commits in
fdroiddata. No attempts to exploit
these have been seen in the git history nor merge requests. Most of these
issues only affect the app building process, e.g.
fdroid build. Repos
made from binary APKs and
fdroid update would only be affected by 4.1.3
Removing weaknesses that could be chained into exploits
The data formats that were used allow for code execution from serialized code. The build metadata files are now loaded with with code serialization disabled, the apkcache file was switched from pickle to JSON, and we will switch the config.py file to YAML with safe loading.
- 4.1.3 OTF-003 — Code Injection in Fdroidserver Metadata Yaml Parsing
- 4.1.31 OTF-031 — Dangerous Deserialization Using Python Pickle in Fdroidserver:update.py
Denial of Service
A few issues were found that allow contributors with trusted access to stop parts of the system from working.
- 4.1.12 OTF-012 — Key Alias Collisions Can Lead to DoS of Publishing in Fdroidserver (issue #553)
- 4.1.13 OTF-013 — Image Bomb Can Lead to DoS in Fdroidserver:update.py
- 4.1.15 OTF-015 — Parsing Untrusted XML Data in Fdroidserver
Experimental drozer integration
As part of the Bazaar2 funding, an experimental feature for integrating Drozer into the fdroid release project was built. This feature is still alpha and is not deployed on any production setup. These issues are real issues, but there are no plans to fix them currently since there are no plans to move forward with the Drozer integration. We welcome contributions by those who want to see that happen.
- 4.1.2 OTF-002 — Shell Code Injection Via Malicious Appids Into Fdroidserver
- 4.1.14 OTF-014 — Insecure Usage of Temporary File/Directory in Fdroidserver Docker/drozer.py
- 4.1.32 OTF-032 — Starting a Process With a Partial Executable Path
- 4.1.11 OTF-011 — Weak Regexps Filtering XSS and Unwanted HTML Tags in Fdroidserver/lint.py
Moving the whole website from Wordpress to a statically generated site paid
large security dividends, there were no actionable issues found with the
be injected into descriptions, both the f-droid.org website and Android
displays the HTML via
with image loading disabled.
Ideally, the index generation process in
fdroid update would have robust
index providers and consumers. This would increase the “herd immunity” of
everyone working with data generated using any of the F-Droid tools.
The links are only displayed in the “Links” section. Since there is a human review of those URLs, and those URLs are committed to git, we have left those to be open without validation. There are also other URLs like home page, issue tracker, etc. I suppose we should show the full URL in the UI if they don’t match a well known pattern. Google Play also includes a link to a website that the app author provides.
One idea for improvement here would be to scan these URLs with the Google Safe Browsing API.
Repomaker is a web tool to make it really easy to set up your own F-Droid repositories. It is a new project that should still be considered beta. There was one issue with high severity (CVE-2018-7753) found in an upstream library, Mozilla’s bleach. It was reported to Mozilla and promptly fixed. There were three other low impact findings which have been fixed.
- 4.1.1 OTF-001 — Evasion of Bleach Sanitizer in Repomaker
- 4.1.29 OTF-029 — Tabnabbing in Repomaker
- 4.1.30 OTF-030 — Repomaker:apk:_def_get_type Allows for Mime Type Mismatches
- 4.1.31 OTF-031 — Unsafe HTML Rendering of Arbitrary Input
Findings that are not relevant or too pedantic
These are issues which are not technically wrong, but are not relevant in the context of how F-Droid is using the code.
- 4.1.16 OTF-016 — Missing file type and size validation
- 4.1.34 OTF-034 — Missing file type and size validation
The download process only downloads files to a private directory. The file validation happens during the install process for all files. After download, the install process validates the SHA-256 against what is in the signed file index.
This code is only used to make JAR signatures on the index.jar for the nearby/swap process. Android protects critical files from deletion with file permissions. Only the index.jar file is ever handled by the zipsigner code.
The NanoHTTPD built-in webserver is only ever used to serve public information. Also, the parts of the code in the NanoHTTPD library that creates temp files is likely never used in F-Droid.
Obfuscation here is used not as a security mechanism, but rather as a lightweight anti-piracy mechanism. The obscured information ultimately need to be available to the app to use it, so there would always be a way to extract the obscured information, as we have seen in the decades of software copy protection arms races.
Filenames in Java are not executed by a shell. Only the
/ character is
problematic with filesystems and file handling code. Ideally, all files
produced by F-Droid software would end up safe no matter where or how they
are used, but it seems that the only manageable way to sanitize files is on
the endpoints that are consuming the files (e.g. fdroidclient or