本周安全专题:Git 深入探讨、Mailchimp 和 SPF

本周安全专题:Git 深入探讨、Mailchimp 和 SPF

源节点: 1910203

第一, git已被审核。 这是由开源技术改进基金 (OSTIF) 赞助的一项工作,该基金是一个致力于提高开源项目安全性的非营利组织。 审计本身是由 X41 和 GitLab 的研究人员完成的,并且 发现两个严重漏洞,都是由相同的不良编码习惯引起的——使用 int 保存缓冲区长度。

在现代系统上, size_t 始终是无符号的,并且位长度与体系结构位宽度相同。 这是字符串和缓冲区长度的正确数据类型,因为在处理长度达到系统上最大可寻址内存时可以保证不会溢出。 另一方面,一个 int 通常是四个字节长并有符号,最大值为 2^31-1,或 2147483647 — 大约 2 GB。 缓冲区很大,但数据量并不是闻所未闻的。 把这么大的东西扔到 git 上,它就会以意想不到的方式崩溃。

我们的第一个示例是 CVE-2022-23521,这是由以下原因引起的越界写入 int 溢出为负数。 A .gitattributes 可以使用修改后的 git 客户端将文件提交到存储库,然后签出该存储库将导致 num_attrs 变量溢出。 将溢出一直推到一个小的负数,然后 git 将大大分配属性缓冲区不足,并将所有数据写入分配的缓冲区末尾之后。

CVE-2022-41903 是另一个有符号整数溢出,这次是漂亮的打印格式被滥用以执行意想不到的操作。 看一下这段代码:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

漏洞利用格式看起来像 %>(2147483647)%a%>(2147483646)%x41,上面的代码针对每个填充实例运行( %>(#) 块)在格式中找到。 第一次执行此代码时,会在输出字符串的前面添加 (2^31)-1 个空格。 该数字恰好是四字节有符号整数的最大值。 但是上面的代码块会再次运行,并且再次将文本添加到缓冲区中,将其长度推到最大整数值之上。 该块的第一行进行隐式转换 size_tint, 环境 sb_len 为负值。

然后在 memcpy() 呼叫, sb->buf 是指向缓冲区开头的指针,sb_len 是溢出的大负数,offset 将是用户控制的值。 这意味着发送到的目的地的位置 memcpy() 可能会无意中设置为比预期缓冲区开头更低的内存位置。 攻击者控制写入。 我已向此文本块添加了一些调试 printf() 语句,并运行测试用例:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

输出的第一个四重奏是设置,用填充将日志行设置为 max int long。 第二个四重奏是缓冲区溢出,其中 sb_len 设置为负数,然后添加到偏移量,为我们提供缓冲区开头左侧 56 字节的位置。 在这种情况下,打印到该位置的内容 %s,它被提交的主题行替换 - 44 字节长。 作者建议,这可以针对“git forge”(又名 GitHub 和 GitLab)进行武器化,因为这些软件套件运行 git archive 命令,该命令可以调用用户控制的漂亮字符串。

修复程序已于 8 月 2200 日推送到 git 源代码,但包含这些修复程序的新版本现在才可用。 原始实例大约有 XNUMX 个 int 问题,即使有一些有趣的技巧,比如 cast_size_t_to_int(),一个内联函数,如果内存超过 2 GB,就会终止程序 size_t 被处理。 所以去更新吧!

Mailchimp——再次

Mailchimp 的人们似乎无法休息,因为 他们的内部管理工具再次被攻击者访问,导致包括 WooCommerce 在内的 133 个客户帐户被曝光。 这是 Mailchimp 去年第三次遭受社会工程或网络钓鱼攻击,每次都会导致向最终用户发送鱼叉式网络钓鱼电子邮件。 因此,如果您在任何 Mailchimp 邮件列表中,请在下次收到相关电子邮件时牢记此漏洞。 (编者注:Hackaday 的两份时事通讯使用了 Mailchimp,我们没有收到通知,所以我们相信我们做得很好。)

皇家邮政勒索软件

在一个可能产生重大后果的故事中, 英国皇家邮政遭遇勒索软件攻击 在他们处理国际邮件的系统上。 此次攻击使用的是 Lockbit 勒索软件,该组织疑似俄语勒索软件团伙。 这可能很重要,因为对实际政府机构的攻击比对企业的攻击严重得多。 由于 Lockbit 作为勒索软件即服务运行,因此很难确定到底是谁发动了攻击。 目前,建议很简单:不要发送任何国际邮件。 钱币。

扫描 SPF 记录

[Sebastian Salla] 有一个可能被认为是奇怪的爱好,其形式是 扫描 SPF 记录以查找奇怪的错误配置。 在他最近的一次冒险中,该扫描是访问量最高的 3 万个域。 并发现配置错误。

但等一下,什么是 SPF,我们为什么要关心? 发件人策略框架是一个 txt 记录,它是域的 DNS 记录的一部分。 它还指定哪些 IP 地址实际上被授权为该域发送电子邮件。 因此,如果传入电子邮件声称来自具有有效 SPF 记录的域,并且发送 IP 地址不在该记录中,则它显然不是真正来自所声明的域。

您所在域的电子邮件因 SPF 问题而被拒绝是招致批评的最可靠方法之一。 因此,让 SPF 记录比应有的更“自由”一点是很诱人的。 最极端的迭代就是打一个 +all 记在您的 SPF 记录上并完成它。 当然,它告诉全世界,使用您的域的每个垃圾邮件发送者实际上都在发送真实的电子邮件,但至少它让老板的外发电子邮件再次正常工作。 超过 XNUMX 个域设置为 SPF +all,显然这个错误比预期的更常见。

真正有趣的是那些配置错误的域的名人录,例如多个美国政府机构、世界各地的其他政府域以及多所大学。 最有趣的是乌克兰国防部,该部门的 SPF 记录是从一架飞机上剪下来的。 -all+all 大约4个月前。

位和字节

Tailscale 发现了一个潜在的严重问题,如果知道另一个客户端的节点 ID,攻击者就可以将该节点添加到自己的 tailnet 中。 这会让攻击者进入您的 VPN 内部,这绝对是一个糟糕的情况。 但在您拿到干草叉之前,易受攻击的代码部署了不到四个月就被修复了。 本月11日私下报道,12日定档。 首先,攻击留下了 Tailscale 能够扫描的日志签名,并得出结论认为它与概念验证测试隔离。 您可以检查自己的仪表板以获取从自己的尾网共享的任何节点以进行确认。 虽然这是一个令人讨厌的漏洞,但对 Tailscale 来说,披露它是有好处的。 许多供应商都会坐视这一问题,但从未将其公开。

Linux 内核存在缓冲区溢出 在其 Netfilter 代码中,缓冲区溢出可能会导致数据泄漏和代码执行。 没有远程利用的途径,但上面链接的电子邮件包含用于本地权限升级的完整 PoC。 如果你喜欢内核开发,谷歌的零项目有 关于该主题的新文章,都是关于空解除引用的。

如果您使用 Zoho 的 ManageEngine,那么如果您尚未更新到修复 CVE-2022-47966 的版本,那么今天您的头发可能会着火。 研究人员在 Horizo​​n3 已经对补丁进行了逆向工程,并泄露了这个 RCE 的秘密。 这是 SAML 单点登录如何实现的问题,部分原因是作为产品一部分打包的非常旧的库。 这是一个非常容易实现的漏洞,所以是时候仔细检查这些安装了!

时间戳记:

更多来自 一日游