ruby - 这个围绕 GPG 的 Ruby 包装器中是否存在明显的安全漏洞？

Question

代码:

require 'tempfile'
require 'open3'

def valid_pgp_key?(unsafe_user_input)

  tempfile = Tempfile.new('pgp_pubkey')

  command = ['gpg',
             '--no-default-keyring',
             '--keyring',
             tempfile.path,
             '--import',
             '-']

  stdin, stderrout, thread = Open3.popen2e(command)

  stdin.puts(unsafe_user_input)
  stdin.close

  exit_status = thread.value
  tempfile.unlink

  exit_status.success? ? true : false
end

unsafe_user_input 是一个完全未净化的字符串，我们希望它是一个有效的 PGP 公钥(但接受它可能是一个有效的 secret key )。

问题:

• 我的理解是，将命令作为数组传递会直接调用 execve()，因此无需担心 shell 注入(inject) - 这是真的吗？
• 恶意用户显然有可能利用这种方法进行 key 验证吗？如果可以，您有什么解决方法？

Answer 1

嗯.. 看起来很简单，不够健壮，但是我们这样看:

1. GPG 的命令行参数以单个 - 结尾，因此 IIRC GPG 将所有以下内容假定为数据，并且无法将其解释为它的选项
2. 它是精确的 GPG 进程的 stdin，而不是整个 shell。如果注入(inject)成功，它除了以一种奇怪的方式运行 GPG 之外几乎什么也做不了。因此，即使攻击成功，如果 GPG 实现得当并且自身不暴露任何漏洞，它也只会让 GPG 任务失败。 (而且我假设 GPG 比 Ruby 的运行时和上面的脚本本身检查得更好，所以这似乎不太可能)
3. command 和execve 部分在我看来是无稽之谈。命令由一些在代码中清晰可见的字符串和一个以标准方式自动生成的临时路径组成。一切要么是常量，要么根本不依赖于用户，因此 command 与 GPG 的常量参数一样安全。
4. 唯一来自用户的是传递给 stdin 的 unsafe_input。它通过 puts 以字符串形式传递给标准输入。 IIRC，它最终将在 unsafe_input 对象提供的 to_s 中结束，但它仍将最终将字符串数据写入管道，GPG 已将其视为数据。同样，它与 GPG 和 Ruby 运行时一样安全。

所以，对我来说，这个脚本是“相对安全的”——“安全”是因为那是简单的代码，我可以阅读它，而且我没有看到任何问题——“相对”只是因为我不不要认为自己是专家，无论是 Ruby 专家还是安全专家。

我可以说我信任 GPG 的代码。如果我正在寻找一些漏洞，我可能会在 Ruby 运行时本身中寻找问题、缓冲区溢出等。我敢打赌它比 GPG 更少检查。 IE。如果用户提供的数据有错误的字符编码和不正确的长度怎么办？ puts 在 stream/pipe 上会发疯吗？等。此外，我还看到了很多其他或多或少邪恶的可能性:让我们即时注入(inject)定制的 Open3.popen2e 实现，然后安全就可以了。但除此之外，如果我们不允许“用户”加载他的任何代码，如果我使用 Ruby 来完成这项工作，并且如果我信任它的运行时 - 我在这里看不到任何问题。