Second Security Audit Results

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.

Privileged Extension

There were no issues found in the Privileged Extension code or the
interaction between F-Droid client and Privileged Extension.

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.

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.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.

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
safe loading.

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.

f-droid.org website

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
Javascript could be injected into descriptions, both the f-droid.org
website and Android client do not let Javascript run from the
descriptions. The f-droid.org website protects against malicious
Javascript injection with a
strict HTTP Content Security Policy.
F-Droid client never runs CSS, Javascript, or dangerous HTML tags
since it displays the HTML via
Html.fromHtml()
with image loading disabled.

Ideally, the index generation process in fdroid update would have
robust CSS/HTML/Javascript checks so malicious injection is prevented
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.

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

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.

Findings that are not relevant or too pedantic

The BluetoothServer is only ever used to serve files to F-Droid
client’s Bluetooth handling, which is nothing like a browser and
definitely does not execute HTML/CSS/Javascript or display websites.
It would not be possible to ever display this information in a browser
without custom code in to receive it.

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.

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 f-droid.org).