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:
(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
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
4.1.24 OTF-024 — (fdroidclient) Raw SQL Query Executions
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
4.1.20 OTF-020 — Unverified URI redirect
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”
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
4.1.35 OTF-035 — Hardcoded root CA keys
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
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”
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
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 OTF-003 .
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
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
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 website. While both findings are correct in that malicious
descriptions. The f-droid.org website protects against malicious
strict HTTP Content Security Policy .
since it displays the HTML via
with image loading disabled.
Ideally, the index generation process in fdroid update would have
by both the index providers and consumers. This would increase the
“herd immunity” of everyone working with data generated using any of
the F-Droid tools.
4.1.37 OTF-037 — Untrusted External Links
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.8 OTF-008 — Unvalidated User Input Included in Response
The BluetoothServer is only ever used to serve files to F-Droid
client’s Bluetooth handling, which is nothing like a browser and
It would not be possible to ever display this information in a browser
without custom code in to receive it.
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.
4.1.21 OTF-021 — File Deleted Unconditionally
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.
4.1.22 OTF-022 — Secure Temp File Usage Recommended
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.
4.1.36 OTF-036 — Use of weak methods for data protection
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.
4.1.38 OTF-038 — Weak pattern matching filter
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 f-droid.org ).
Read more at: https://f-droid.org/en/2018/09/04/second-security-audit-results.html
The second full security audit of F-Droid is complete. We aresatisfied with the results, which confirmed again that the coresecurity model and standard oper...f-droid.org