第二次安全审计结果

F-Droid 的第二次全面安全审计已完成。我们对结果感到满意,这再次证实了核心安全模型和标准操作是可靠的。审计指出了核心构建过程中的问题,我们目前依靠可信贡献者的手动审查来保护我们。该审计还表明,即使在连接到恶意服务器时,我们仍需努力实现保持 Android 客户端安全的目标,例如,如果手动添加由其运营商创建的不受信任的存储库以供利用。完整的审计报告可在此下载:report_otf_fdroid.pdf (缓存副本)

审计由 Radically Open Security 进行,这是 F-Droid 的天然合作伙伴,因为他们同样关注自由软件和开放流程。感谢 Open Tech Fund 找到审计员并支付雇用他们的费用。

有关 F-Droid 的安全实践的更多信息,请参阅有关安全模型的文档。

降低信任要求

这次审计的一个关键部分是推动我们进一步降低 F-Droid 中所有流程中各个部分和参与者所需的信任级别。客户端/服务器系统通常是围绕服务器操作者完全受信任的假设构建的。有许多值得信赖的贡献者在 F-Droid 上工作,核心部分的工作人员有着长期而良好的记录。尽管如此,拥有一个不需要信任人们和他们的计算机的系统是非常有价值的。我们的目标是推动 F-Droid 生态系统的所有部分根据最小特权原则工作。

新应用和更新通过合并请求和 git 提交提交到 fdroiddata。然后这些更改将永久存储在 git 历史记录中。过去,代码信任 fdroiddata 中的所有内容,因为人类会审查提交是否存在任何恶意数据。该模型在 F-Droid 以及许多人公开开发的许多其他项目中都有很好的记录。Debian 就是一个很好的例子,因为几乎有一千名 Debian 开发人员拥有提交权限,这可以让他们在每台运行 Debian 的机器上获得 root 权限。

这次审计帮助我们提出了一个问题:在不改变贡献者工作方式的情况下,可以限制或删除哪些权限?它还发现了一些问题,其中代码信任来自 fdroiddata 的输入,这些输入已经由人类提交和审查,但这可能指向其他可能包含漏洞的代码。

减少对各个部分的信任可以减少贡献的压力,并允许我们作为一个社区向各种贡献者开放更多的东西。如果贡献者认为他们的审核是防止利用 F-Droid 的最后一道防线,那会给审核增加很大的压力。

特权扩展

在特权扩展代码或 F-Droid 客户端与特权扩展之间的交互中没有发现问题。

F-Droid 客户端

这一发现将 Android 中的标准做法标记为不安全:“可以在设备上安装 SSL 证书并运行应用以在代理上捕获其流量。” Android 不会让意外在设备上包含证书变得容易,并且它还会在证书到位时发出持续通知。我们认为,遵循此建议不会显着提高现实世界的安全性。它将消除在设备上安装证书以检查流量的合法用例。例如:必须检查流量以符合规定的公司防火墙;或者,在正常操作期间审核 F-Droid 的真实流量。

这只能被利用来更改在 TOFU 提示中显示给用户的 URL。用户负责确认该提示中列出的内容。它应该被修复,但似乎并不紧急。当我们对整个“应用存储库”流程进行大修时,它将包括在内。

这是 Android 本身的问题。如果 APK 使用 SHA256 签名,该 APK 不适用于 Android < 4.3。使用更大的 RSA 签名密钥也将是理想的。但是由于 Android 不支持迁移签名密钥,这将是一个非常困难的项目。F-Droid 包含用于验证 APK 的其他保护层,包括 APK 的 GPG 签名以及整个安全的 F-Droid 发行版机制。

HTTPS 固定机制肯定可以改进。由于 HTTPS 固定对于安全操作不是必不可少的,因此它从来都不是高优先级。文件服务器的完整性仍然受到索引文件签名的保护。对于 f-droid.org 和 Guardian Project 存储库,检查这些签名的密钥内置在客户端中。

附近/交换

4.1.10 OTF-010 是一个严重的问题,由于 Radially Open Security 的开放审计过程,它一被发现就得到了修复。它使得通过交换过程发送网络钓鱼提示成为可能,但只能从目标设备所在的同一网络中被利用。

附近交换的安全性主要建立在有限的攻击范围之上,因为它只能通过蓝牙或仅限于当前子网的本地 Wi-Fi 工作。它也仅在非常有限的时间内处于活动状态,而用户直接使用它。然后,为了文件完整性,索引签名密钥在第一次使用时是受信任的,然后所有文件都根据已验证的索引进行验证。虽然该过程的安全性肯定可以提高,但它旨在取代其他广泛使用的不太安全的方法。

理想情况下,所有蓝牙连接都将使用本机蓝牙加密,所有 IP 连接都将使用 HTTPS。如果没有大量工作,与添加对它们的支持相关的可用性问题可能会使附近/交换功能几乎无用。

fdroidserver

努力实现最小权限

构建元数据文件用于描述应用及其构建过程。它们通常由受信任的各方(例如运行存储库的人)创建或通过合并请求进行审核。这些发现只会对包含来自未经审核不受信任来源的元数据文件的存储库造成问题。对于 f-droid.org,元数据文件只能通过 fdroiddata 中的 git 提交下载到生产服务器。在 git 历史记录和合并请求中都没有发现利用这些的尝试。大多数这些问题只会影响应用构建过程,例如fdroid 构建。由二进制 APK 和 fdroid 更新 生成的存储库仅受 4.1.3 OTF-003 影响。

消除可能被链接以进行漏洞利用的弱点

使用的数据格式允许从序列化代码执行代码。构建元数据文件现在加载时禁用代码序列化,apkcache 文件从 pickle 切换到 JSON,并且我们将会把 config.py 文件迁移到安全加载到 YAML。

拒绝服务

发现了一些问题,允许具有受信任访问权限的贡献者阻止系统的某些部分工作。

实验性的 drozer 集成

作为 Bazaar 2 资助的一部分,我们构建了将 Drozer 集成到 fdroid 发行项目的实验功能。此功能仍处于 alpha 阶段,未部署在任何生产设置中。这些问题是实际的问题,但目前没有修复它们的计划,因为没有计划来推进 Drozer 集成。我们欢迎那些希望看到进展的人作出贡献。

f-droid.org 网站

将整个网站从 Wordpress 迁移到静态生成的网站带来了巨大的安全红利,并且没有发现网站存在可操作的问题。虽然这两个发现都是正确的,因为可以将恶意 Javascript 注入描述,但 f-droid.org 网站和 Android 客户端都不允许从描述中运行 Javascript。 f-droid.org 网站通过严格的 HTTP 内容安全策略防止恶意 Javascript 注入。 F-Droid 客户端从不运行 CSS、Javascript 或危险的 HTML 标签,因为它通过 Html.fromHtml() 禁用图像加载。

理想情况下,fdroid update 中的索引生成过程将具有强大的 CSS/HTML/Javascript 检查,因此索引提供者和消费者都可以防止恶意注入。这将提高使用任何 F-Droid 工具生成的数据的每个人的“群体免疫”。

链接仅显示在“链接”部分。由于对这些 URL 进行了人工审核,并且这些 URL 已提交给 git,因此我们将这些 URL 保留为打开状态而不需要验证。还有其他 URL,例如主页、问题跟踪器等。我想如果它们与众所周知的模式不匹配,我们应该在 UI 中显示完整的 URL。Google Play 还包含指向应用作者提供的网站的链接。

此处改进的一个想法是使用 Google 安全浏览 API 扫描这些 URL。

Repomaker

Repomaker 是一个网络工具,可以让你轻松设置自己的 F-Droid 存储库。这是一个新项目,仍应被视为测试版。在上游库 Mozilla 的 bleach 中发现了一个高危问题 (CVE-2018-7753)。已向 Mozilla 报告并及时修复。还有其他三个影响较小的发现已得到修复。

不相关或过于迂腐的发现

这些问题在技术上没有错,但在 F-Droid 所使用的代码的情况下无关。

BluetoothServer 仅用于为 F-Droid 客户端的蓝牙处理提供文件,这与浏览器完全不同,绝对不会执行 HTML/CSS/Javascript 或显示网站。如果没有自定义代码来接收它,就不可能在浏览器中显示这些信息。

下载过程仅将文件下载到私有目录。文件验证发生在所有文件的安装过程中。下载后,安装过程会根据签名文件索引中的内容验证 SHA-256。

此代码仅用于在 index.jar 上为附近/交换进程制作 JAR 签名。 Android 通过文件权限保护关键文件不被删除。只有 index.jar 文件由 zipsigner 代码处理。

NanoHTTPD 内置网络服务器仅用于提供公共信息。此外,NanoHTTPD 库中创建临时文件的部分代码可能从未在 F-Droid 中使用。

这里的混淆不是用作安全机制,而是用作轻量级的反盗版机制。隐藏信息最终需要对应用可见才能使用,因此总会有一种方法可以提取隐藏信息,正如我们在数十年的软件复制保护军备竞赛中所看到的那样。

Java 中的文件名不是由 shell 执行的。只有 / 字符对文件系统和文件处理代码有问题。理想情况下,F-Droid 软件生成的所有文件最终都会安全,无论它们在何处或以何种方式使用,但似乎唯一可管理的清理文件的方法是在使用文件的端点上(例如 fdroidclientf-droid.org)。