安全漏洞修复

此拉取请求修复了此项目中存在的 1.) 临时目录劫持漏洞，或 2.) 临时目录信息泄露漏洞。

前言

系统临时目录在大多数类 unix 系统（不是 MacOS 或 Windows）上的所有用户之间共享。因此，与系统临时目录交互的代码必须注意该目录中的文件交互，并且必须确保设置了正确的文件权限。

生成此 PR 是因为在此存储库中检测到以下调用链，其方式使该项目容易受到攻击。
File.createTempFile(..)-> file.delete()->file.mkdir()或者file.mkdirs().

影响

此漏洞可能会产生两种影响之一，具体取决于它是哪种漏洞。

1. 临时目录信息泄露 – 此目录中的信息对其他本地用户可见，允许恶意行为者共同驻留在同一台机器上查看潜在的敏感文件。
2. 临时目录劫持漏洞 – 影响与上述 1. 相同，而且本地用户可以操作/向该目录添加内容。如果在此临时目录之外执行代码，则可能导致本地权限升级。

临时目录劫持

file.mkdir()存在此漏洞是因为未检查or的返回值file.mkdirs()以确定调用是否成功。举例来说，因为另一个本地用户在此过程之前创建了目录。

File tmpDir = File.createTempFile("temp", ".dir"); // Attacker knows the full path of the directory that will be later created
// delete the file that was created
tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before the java code.
// and makes a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
// Attacker can write any new files to this directory that they wish.
// Attacker can read any files created within this directory.

其他例子

• CVE- 2021-20202 – 钥匙斗篷/钥匙斗篷
• CVE-2020-27216 – eclipse/jetty.project

临时目录信息公开

file.mkdir()存在此漏洞的原因是，虽然或的返回值file.mkdirs()被正确检查，但创建的目录的权限遵循默认系统uname设置。因此，创建的目录具有每个人都可读的权限。因此，系统上的所有其他本地用户都可以查看写入此目录的任何文件/目录。

File tmpDir = File.createTempFile("temp", ".dir");
tmpDir.delete();
if (!tmpDir.mkdirs()) { // Guard correctly prevents temporary directory hijacking, but directory contents are everyone-readable.
    throw new IOException("Failed to create temporary directory");
}

其他例子

• CVE-2020-15250 – junit 团队/junit
• CVE-2021-21364 – swagger-api/swagger-codegen
• CVE-2022-24823 – 网络/网络
• CVE-2022-24823 – 网络/网络

修复

解决方法是将上述逻辑转换为使用 Java 1.7 中引入的以下 API。

File tmpDir = Files.createTempDirectory("temp dir").toFile();

API 都安全地创建了目录，即使用随机的、不冲突的名称，目录权限只允许当前执行的用户读取或写入该目录的内容。

➡️漏洞披露⬅️

?漏洞披露是漏洞处理过程中超级重要的一环，不容忽视！这对您来说可能是全新的，没关系，我是来帮忙的！

第一个问题，我们需要进行漏洞披露吗？这取决于！

1. 易受攻击的代码是否仅在测试或示例代码中？无需披露！
2. 代码中易受攻击的代码是否已交付给您的最终用户？可能需要漏洞披露！

漏洞披露方法

您有几个选项来执行漏洞披露。但是，我想建议以下两个选项：

1. 通过创建存储库级别的GitHub 安全公告向 GitHub 请求 CVE 编号。这样做的好处是，如果您提供足够的信息，GitHub 会自动为您的下游消费者生成 Dependabot 警报，从而更快地解决此漏洞。
2. 联系 Snyk 团队以协助 CVE 发布。可以通过Snyk 的披露电子邮件联系到他们。

检测这个和未来的漏洞

GitHub 的LGTM.com使用此CodeQL 查询自动检测到此漏洞。

您可以通过启用免费的（开源的）GitHub Action来自动检测类似的未来漏洞。

我不是 GitHub 的员工，我只是一名开源安全研究员。

来源

此贡献是使用OpenRewrite 重构配方自动生成的，该配方经过精心手工制作，可将此安全修复程序引入您的存储库。

可以在此处找到生成此 PR 的源代码：
UseFilesCreateTempDirectory

选择退出

如果您想像这样选择退出未来的自动安全漏洞修复，请考虑添加一个调用
.github/GH-ROBOTS.txt到您的存储库的文件，其中包含以下行：

User-agent: JLLeitschuh/security-research
Disallow: *

此机器人将尊重ROBOTS.txt格式以供将来贡献。

或者，如果不再积极维护此项目，请考虑存档存储库。

CLA要求

仅当您的项目要求贡献者为外部贡献签署贡献者许可协议 (CLA) 时，此部分才相关。

我不太可能直接签署 CLA。但是，所有贡献的提交都已经自动签署。

签核的含义取决于项目，但它通常证明提交者有权在相同许可下提交此作品并同意开发者原产地证书
（有关更多信息，请参阅https://developercertificate.org/）。

– Git Commit Signoff 文档

如果签署贵组织的 CLA 是合并此贡献的严格要求，请随时关闭此 PR。

赞助与支持

此贡献由 HUMAN Security Inc. 和新的 Dan Kaminsky 奖学金赞助，该奖学金旨在通过资助开源工作来纪念 Dan 的记忆和遗产，使世界变得更美好（和更安全）。

此 PR 由Moderne生成，Moderne是一种免费的开源 SaaS 产品，它使用保留格式的 AST 转换来修复错误、标准化代码样式、应用最佳实践、迁移库版本并大规模修复常见的安全漏洞。

追踪

作为此修复的一部分生成的所有 PR 都在此处跟踪：JLLeitschuh/security-research#10