7-Zip漏洞集
2022-04-20 10:11:39 
阿炯
拖动文件就能触发 7-Zip 安全漏洞，波及所有版本
7-Zip 是一款开源的解压缩软件，主要应用在微软 Windows 操作系统上。7-Zip 的作者曾在2021年3月发布了首个针对 Linux 的官方版本，让 Linux 用户可以使用官方开发的 7-Zip 替换掉年久失修的 p7zip。
2022年4月，研究人员 Kağan Çapar 在 7-Zip 中发现了一个漏洞，该漏洞可能导致黑客被赋予更高的权限以及执行任意指令。该漏洞的 CVE ID 为 CVE-2022-29072，漏洞影响 7-Zip 所有版本，其中也包括目前最新的 21.07 版本。
要想触发该漏洞也十分简单，用户只需将带有 .7z 扩展名的文件拖到 7-Zip 软件窗口的「帮助 > 内容区」，触发方式可以查看下方的 GIF 图。
漏洞是由于 7z.dll 的错误配置和堆栈溢出所导致的。在软件安装后，「帮助 > 内容」区域中的文件通过 Windows HTML Helper 进行工作，但在进行命令注入后，7zFM.exe 下会出现一个子进程，由于 7z.dll 文件存在内存交互，调出的 cmd.exe 子进程会被授予管理员模式。
7-Zip 的开发者暂时还没提供软件更新来修复该漏洞，也尚不清楚 7-Zip 何时会解决该问题。7-Zip 最后一次更新还停留在 2021 年 12 月。
临时解决方法
虽然官方还没有提供更新来修复该漏洞，但该漏洞是由安装文件夹中包含的 7-zip.chm 文件所引起的，因此目前的临时解决方案就是删除这个受影响的文件。
7-zip.chm 是一个帮助文件，包含关于如何使用和运作 7-Zip 的信息。删除该文件并不会导致功能缺失。删除后，当用户在 7-Zip 文件管理器中选择「帮助 > 内容」或按键盘上的 F1 键时，帮助文件将不再打开。
为了删除该文件，必须首先打开压缩程序的文件夹。一般情况下，该文件可以在 C:\\Programs\下找到。调出 "7-Zp" 文件夹后，可以简单地通过右键点击删除 7-zip.chm 文件。除了删除 7-zip.chm 文件，用户还可以撤销 7-Zip 程序的写入权限，让 7-Zip 只能运行和读取文件。
大乌龙：7-Zip 伪开源还留有后门
2022年7月上旬，一位名为 Paul 的作者发布了一篇呼吁抵制知名压缩软件 7-Zip 的文章。7-Zip 是一个由俄罗斯开发者 Igor Pavlov 开发，发布于 1999 年的老牌软件，其源码托管在 Sourceforge；大部分的源码都适用于 GNU LGPL 许可，unRAR 代码则采用的是 GNU LGPL + unRAR 限制的混合许可证。其首先抨击 7-Zip 的点在于，他认为该软件是 “有限的” 开源。原因则在于：7-Zip 的代码没有托管在 Github、Gitlab 或任何一个公共代码托管平台上，只有一个 Sourceforge 官方页面上的 src.7z。“没有历史、没有 committer、没有名字、也没有文档，只有一个存档”。他还引用了一个 2010 年的讨论帖来指出，从源码构建 7-Zip 存在很大难度。“如果你需要自己编译 7-zip - 一些 tweaks 是不可避免的。那么为什么需要 tweaks 而没有 commit history 呢？只是因为作者不想让你从源代码中构建应用程序，而且有些部分可能没有包括在内，或者包含了一些'special' bugs。有了 commit history，可以更轻松地跟踪任何更改并还原任何错误的部分；也更容易运送一些见不得光的元素，如隐藏的遥测或后门。”
且 Paul 认为，Sourceforge 的声誉并不好；因为该平台曾被指控在 Windows .exe 文件和自解压文件中包含间谍软件和恶意软件。此外，该作者还列举了一些 7-Zip 存在的安全漏洞。最后，他抵制 7-Zip 还有一个关键原因是俄乌冲突：“最好不要使用俄罗斯的软件，不仅仅是出于对乌克兰的声援，该软件还可能增加高级安全风险。”
文章还指出了 7-Zip 的一些替代方案，其中包括 Nanazip（7-Zip 分支）和基于 FreePascal 的 PeaZip 等。这一抵制博文不可避免的在 Reddit 上引起了热议，但就当下情况来看，还是与 Paul 持相反意见的人居多。其中一位名为 qvop 的网友就针对博客中的内容逐一进行了反驳。
首先，7-Zip 就是开源的（忽略 unRAR 许可部分），没有任何一项规定指出开源软件的源码必须托管在某个特定平台；有问题的是 Paul 自身。其次，事实上是存在一些（公认的相对稀少的）文件，内容包括更新日志以及关于如何编译程序和它的一些内部工作的描述。而一些其余的内容也并不在开源发布的要求规范内，且如果开发者是单独开发而不寻求贡献的话，其作用也不大。
关于后门之类的指控，则更像是接近阴谋论的范畴了。没有任何实际证据表明开发者有意加大编译难度，或者故意包含 "special bugs"。相反，开发团队在开发和维护这个软件方面有超过 20 年的记录，他们显然没有过文章作者所暗示的种种意图或行为；在不同环境下编译软件的问题是完全正常的。同理，难道开发人员现在还在与 Sourceforge 合作在提供的二进制文件中隐藏恶意软件？这一指控同样也没有实际证据。
最后关于站队。因为开发者的国籍而抵制开源软件是一个愚蠢的举措，尤其在开发团队并没有表明立场的情况下。“我不确定开发人员被迫在 7zip 中包含恶意代码的实际风险有多大，但我认为如果普京想要渗透开源软件，会有很多更简单、更隐蔽的方法。”
总而言之，这在我看来是一个无稽之谈，掺杂着一些权利和阴谋论。
网友 JonnyRocks：发帖人不喜欢 7-zip 创建者的名字，想 fork 它，结果被搞糊涂了。
网友 bemenaker：nanazip 是 7zip 的一个分支。它也有 7zip 所缺少的 win11 集成。我不是在为这篇博文辩护，只是想说那个作者是个白痴。
网友 boom_bap_bnc：我会继续使用它，谢谢。
网友 atoponce 则感叹道 “奇奇怪怪”：并非所有的开源软件都有公开的源代码库和 commit 历史。安全问题当然令人担忧，但在 SourceForge 上托管源代码和二进制文件是完全可以的。文章中引用的恶意软件争议在 7 年前就已经结束了。
最后，因为开源软件的总部在俄罗斯而抵制它是很奇怪的，更何况 7-Zip 的作者也并没有因为你使用该软件而赚到钱。
加密 ZIP 文件可以存在两个正确的密码
Positive Technologies 的网络安全研究员 Arseniy Sharoglazov 于2022年8月下旬在社交平台分享了一个简单的实验并指出，加密的 ZIP 文件可能存在两个正确的密码，并且都可以提取出相同的结果。
“创建 ZIP：7z a http://x.zip/etc/passwd -mem=AES256 -p
使用这个密码：Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
提取它：7z e http://x.zip
使用这个密码：pkH8a0AqNbHcdw8GrmSp
Magic!”
Sharoglazov 制作了一个名为 x.zip 的受密码保护的 ZIP 文件，选择的密码是 1987 年的热门英文歌曲的双关语：
Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
但实验结果表明，当他使用一个完全不同的密码（pkH8a0AqNbHcdw8GrmSp）提取 x.zip 时，不会收到任何的报错信息。
对此，BleepingComputer 使用不同的 ZIP 程序成功地对该实验进行了复现。该网站使用了 p7zip（相当于 macOS 的 7-Zip）和另一个叫 Keka 的 ZIP 工具，与 Sharoglazov 一样在创建时采用了较长的密码，并启用了 AES-256 加密模式。结果表明，虽然 ZIP 使用较长的密码加密，但使用任一密码都能成功提取了存档。
一些网友在 Sharoglazov 的动态下针对该实验进行了讨论，一位 ID 为 Unblvr 的用户指出，造成这个结果的原因可能在于：
ZIP 使用 PBKDF2，如果输入太大，它会 hash 输入 。该 hash（作为原始字节）成为实际密码。尝试使用 SHA1 对第一个密码进行 hash，并将十六进制摘要解码为 ASCII... :)
在启用 AES-256 模式生成受密码保护的 ZIP 存档时 ，如果密码太长，ZIP 格式会使用 PBKDF2 算法并对用户提供的密码进行 hash 处理。在这种情况下，这个新计算的 hash 将会成为文件的实际密码。研究人员解释称，太长是指超过 64 个字节（字符）。
当用户试图提取文件，并输入一个超过 64 字节的密码时，用户的输入将再次由 ZIP 应用程序进行 hash，并与正确的比较密码（现在本身就是一个 hash）。如果匹配，将可以成功进行文件提取。
示例中使用的替代密码 pkH8a0AqNbHcdw8GrmSp 实际上是较长密码 SHA-1 hash 的 ASCII 表示。Nev1r-G0nna-G2ve-... 的 SHA-1 checksum = 706b4838613041714e62486364773847726d5370。此校验和在转换为 ASCII 时产生：pkH8a0AqNbHcdw8GrmSp。
但是值得注意的是，在加密或解密文件时，仅当密码长度大于 64 个字符时才会进行 hash 处理。换句话说，较短的密码在压缩或解压缩 ZIP 的任何阶段都不会出现这种情况。这也是为什么在加密阶段选择长的 "Nev1r-G0nna-G2ve-..." 字符串作为密码时，ZIP 程序设置的实际密码实际上是该字符串的 (SHA1) hash。
如果在解密阶段输入 Nev1r-G0nna-G2ve-...，它将被 hash 并与之前存储的密码（即 SHA1 hash）进行比较。但是，在解密阶段输入较短的 “pkH8a0AqNbHcdw8GrmSp” 密码将使应用程序直接将此值与存储的密码（也就是 SHA1 hash）进行比较。更多的技术见解可参见 Wikipedia 上 PBKDF2 的 HMAC collisions 小节。
“当使用 HMAC 作为其伪随机函数时，PBKDF2 有一个有趣的特性。可以轻松地构造任意数量的不同密码对，每对密码对都存在冲突。如果提供的密码长于底层 HMAC hash function 的块大小，则首先要将密码 pre-hashed 成一个 digest，然后将该 digest 作为密码使用。”
不过，同一个 ZIP 有两个可能的密码这一事实并不代表存在有安全漏洞；因为生成密码的 hash 的前提是需要知道原始密码。
7-Zip 是一款开源的解压缩软件，主要应用在微软 Windows 操作系统上。7-Zip 的作者曾在2021年3月发布了首个针对 Linux 的官方版本，让 Linux 用户可以使用官方开发的 7-Zip 替换掉年久失修的 p7zip。
2022年4月，研究人员 Kağan Çapar 在 7-Zip 中发现了一个漏洞，该漏洞可能导致黑客被赋予更高的权限以及执行任意指令。该漏洞的 CVE ID 为 CVE-2022-29072，漏洞影响 7-Zip 所有版本，其中也包括目前最新的 21.07 版本。
要想触发该漏洞也十分简单，用户只需将带有 .7z 扩展名的文件拖到 7-Zip 软件窗口的「帮助 > 内容区」，触发方式可以查看下方的 GIF 图。
漏洞是由于 7z.dll 的错误配置和堆栈溢出所导致的。在软件安装后，「帮助 > 内容」区域中的文件通过 Windows HTML Helper 进行工作，但在进行命令注入后，7zFM.exe 下会出现一个子进程，由于 7z.dll 文件存在内存交互，调出的 cmd.exe 子进程会被授予管理员模式。
7-Zip 的开发者暂时还没提供软件更新来修复该漏洞，也尚不清楚 7-Zip 何时会解决该问题。7-Zip 最后一次更新还停留在 2021 年 12 月。
临时解决方法
虽然官方还没有提供更新来修复该漏洞，但该漏洞是由安装文件夹中包含的 7-zip.chm 文件所引起的，因此目前的临时解决方案就是删除这个受影响的文件。
7-zip.chm 是一个帮助文件，包含关于如何使用和运作 7-Zip 的信息。删除该文件并不会导致功能缺失。删除后，当用户在 7-Zip 文件管理器中选择「帮助 > 内容」或按键盘上的 F1 键时，帮助文件将不再打开。
为了删除该文件，必须首先打开压缩程序的文件夹。一般情况下，该文件可以在 C:\\Programs\下找到。调出 "7-Zp" 文件夹后，可以简单地通过右键点击删除 7-zip.chm 文件。除了删除 7-zip.chm 文件，用户还可以撤销 7-Zip 程序的写入权限，让 7-Zip 只能运行和读取文件。
大乌龙：7-Zip 伪开源还留有后门
2022年7月上旬，一位名为 Paul 的作者发布了一篇呼吁抵制知名压缩软件 7-Zip 的文章。7-Zip 是一个由俄罗斯开发者 Igor Pavlov 开发，发布于 1999 年的老牌软件，其源码托管在 Sourceforge；大部分的源码都适用于 GNU LGPL 许可，unRAR 代码则采用的是 GNU LGPL + unRAR 限制的混合许可证。其首先抨击 7-Zip 的点在于，他认为该软件是 “有限的” 开源。原因则在于：7-Zip 的代码没有托管在 Github、Gitlab 或任何一个公共代码托管平台上，只有一个 Sourceforge 官方页面上的 src.7z。“没有历史、没有 committer、没有名字、也没有文档，只有一个存档”。他还引用了一个 2010 年的讨论帖来指出，从源码构建 7-Zip 存在很大难度。“如果你需要自己编译 7-zip - 一些 tweaks 是不可避免的。那么为什么需要 tweaks 而没有 commit history 呢？只是因为作者不想让你从源代码中构建应用程序，而且有些部分可能没有包括在内，或者包含了一些'special' bugs。有了 commit history，可以更轻松地跟踪任何更改并还原任何错误的部分；也更容易运送一些见不得光的元素，如隐藏的遥测或后门。”
且 Paul 认为，Sourceforge 的声誉并不好；因为该平台曾被指控在 Windows .exe 文件和自解压文件中包含间谍软件和恶意软件。此外，该作者还列举了一些 7-Zip 存在的安全漏洞。最后，他抵制 7-Zip 还有一个关键原因是俄乌冲突：“最好不要使用俄罗斯的软件，不仅仅是出于对乌克兰的声援，该软件还可能增加高级安全风险。”
文章还指出了 7-Zip 的一些替代方案，其中包括 Nanazip（7-Zip 分支）和基于 FreePascal 的 PeaZip 等。这一抵制博文不可避免的在 Reddit 上引起了热议，但就当下情况来看，还是与 Paul 持相反意见的人居多。其中一位名为 qvop 的网友就针对博客中的内容逐一进行了反驳。
首先，7-Zip 就是开源的（忽略 unRAR 许可部分），没有任何一项规定指出开源软件的源码必须托管在某个特定平台；有问题的是 Paul 自身。其次，事实上是存在一些（公认的相对稀少的）文件，内容包括更新日志以及关于如何编译程序和它的一些内部工作的描述。而一些其余的内容也并不在开源发布的要求规范内，且如果开发者是单独开发而不寻求贡献的话，其作用也不大。
关于后门之类的指控，则更像是接近阴谋论的范畴了。没有任何实际证据表明开发者有意加大编译难度，或者故意包含 "special bugs"。相反，开发团队在开发和维护这个软件方面有超过 20 年的记录，他们显然没有过文章作者所暗示的种种意图或行为；在不同环境下编译软件的问题是完全正常的。同理，难道开发人员现在还在与 Sourceforge 合作在提供的二进制文件中隐藏恶意软件？这一指控同样也没有实际证据。
最后关于站队。因为开发者的国籍而抵制开源软件是一个愚蠢的举措，尤其在开发团队并没有表明立场的情况下。“我不确定开发人员被迫在 7zip 中包含恶意代码的实际风险有多大，但我认为如果普京想要渗透开源软件，会有很多更简单、更隐蔽的方法。”
总而言之，这在我看来是一个无稽之谈，掺杂着一些权利和阴谋论。
网友 JonnyRocks：发帖人不喜欢 7-zip 创建者的名字，想 fork 它，结果被搞糊涂了。
网友 bemenaker：nanazip 是 7zip 的一个分支。它也有 7zip 所缺少的 win11 集成。我不是在为这篇博文辩护，只是想说那个作者是个白痴。
网友 boom_bap_bnc：我会继续使用它，谢谢。
网友 atoponce 则感叹道 “奇奇怪怪”：并非所有的开源软件都有公开的源代码库和 commit 历史。安全问题当然令人担忧，但在 SourceForge 上托管源代码和二进制文件是完全可以的。文章中引用的恶意软件争议在 7 年前就已经结束了。
最后，因为开源软件的总部在俄罗斯而抵制它是很奇怪的，更何况 7-Zip 的作者也并没有因为你使用该软件而赚到钱。
加密 ZIP 文件可以存在两个正确的密码
Positive Technologies 的网络安全研究员 Arseniy Sharoglazov 于2022年8月下旬在社交平台分享了一个简单的实验并指出，加密的 ZIP 文件可能存在两个正确的密码，并且都可以提取出相同的结果。
“创建 ZIP：7z a http://x.zip/etc/passwd -mem=AES256 -p
使用这个密码：Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
提取它：7z e http://x.zip
使用这个密码：pkH8a0AqNbHcdw8GrmSp
Magic!”
Sharoglazov 制作了一个名为 x.zip 的受密码保护的 ZIP 文件，选择的密码是 1987 年的热门英文歌曲的双关语：
Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You
但实验结果表明，当他使用一个完全不同的密码（pkH8a0AqNbHcdw8GrmSp）提取 x.zip 时，不会收到任何的报错信息。
对此，BleepingComputer 使用不同的 ZIP 程序成功地对该实验进行了复现。该网站使用了 p7zip（相当于 macOS 的 7-Zip）和另一个叫 Keka 的 ZIP 工具，与 Sharoglazov 一样在创建时采用了较长的密码，并启用了 AES-256 加密模式。结果表明，虽然 ZIP 使用较长的密码加密，但使用任一密码都能成功提取了存档。
一些网友在 Sharoglazov 的动态下针对该实验进行了讨论，一位 ID 为 Unblvr 的用户指出，造成这个结果的原因可能在于：
ZIP 使用 PBKDF2，如果输入太大，它会 hash 输入 。该 hash（作为原始字节）成为实际密码。尝试使用 SHA1 对第一个密码进行 hash，并将十六进制摘要解码为 ASCII... :)
在启用 AES-256 模式生成受密码保护的 ZIP 存档时 ，如果密码太长，ZIP 格式会使用 PBKDF2 算法并对用户提供的密码进行 hash 处理。在这种情况下，这个新计算的 hash 将会成为文件的实际密码。研究人员解释称，太长是指超过 64 个字节（字符）。
当用户试图提取文件，并输入一个超过 64 字节的密码时，用户的输入将再次由 ZIP 应用程序进行 hash，并与正确的比较密码（现在本身就是一个 hash）。如果匹配，将可以成功进行文件提取。
示例中使用的替代密码 pkH8a0AqNbHcdw8GrmSp 实际上是较长密码 SHA-1 hash 的 ASCII 表示。Nev1r-G0nna-G2ve-... 的 SHA-1 checksum = 706b4838613041714e62486364773847726d5370。此校验和在转换为 ASCII 时产生：pkH8a0AqNbHcdw8GrmSp。
但是值得注意的是，在加密或解密文件时，仅当密码长度大于 64 个字符时才会进行 hash 处理。换句话说，较短的密码在压缩或解压缩 ZIP 的任何阶段都不会出现这种情况。这也是为什么在加密阶段选择长的 "Nev1r-G0nna-G2ve-..." 字符串作为密码时，ZIP 程序设置的实际密码实际上是该字符串的 (SHA1) hash。
如果在解密阶段输入 Nev1r-G0nna-G2ve-...，它将被 hash 并与之前存储的密码（即 SHA1 hash）进行比较。但是，在解密阶段输入较短的 “pkH8a0AqNbHcdw8GrmSp” 密码将使应用程序直接将此值与存储的密码（也就是 SHA1 hash）进行比较。更多的技术见解可参见 Wikipedia 上 PBKDF2 的 HMAC collisions 小节。
“当使用 HMAC 作为其伪随机函数时，PBKDF2 有一个有趣的特性。可以轻松地构造任意数量的不同密码对，每对密码对都存在冲突。如果提供的密码长于底层 HMAC hash function 的块大小，则首先要将密码 pre-hashed 成一个 digest，然后将该 digest 作为密码使用。”
不过，同一个 ZIP 有两个可能的密码这一事实并不代表存在有安全漏洞；因为生成密码的 hash 的前提是需要知道原始密码。