「没有对手?我有话说!」Gate广场挑战赛——秀操作赢$2,000,百万流量加持!
你是下一个明星交易员吗?
想让自己的名字闪耀广场热搜?想吸引数万追随者?百万流量已就位,就等你来承接!
🎉 双重豪礼,赢家通吃!
1️⃣ 晒单排行榜奖励
收益率排名前10的用户,瓜分 $1,500合约体验券!巅峰对决等你来战!
2️⃣ 晒单幸运奖
随机抽取10位用户,每人赠送 $50跟单包赔券!即使不是大神,也有机会躺赢!
🎮 参与方式超简单!
✅ 在 Gate广场 晒出你的交易战绩,并成为带单员!
✨ 发帖要求:
内容必须原创,并带上 #CopyTrading# 或 #跟单# 标签
附上 收益率截图 或 交易卡片,并分享你的 独家交易心得
严禁AI生成虚假交易,一经发现取消资格
观点犀利、逻辑清晰,干货越多越吸粉!
⏰ 活动截止:8月15日 10:00(UTC+8)
【立即发帖】 展现你的王者操作,承接百万流量,成为下一个交易传奇!
💬 还在等什么?Gate广场,等你来战! 💪
微软Windows早期版本0day漏洞分析:从提权到利用全流程
微软Windows系统0day漏洞分析及利用
近期,微软发布的安全补丁中修复了一个正在被利用的win32k提权漏洞。该漏洞仅存在于早期Windows系统版本中,无法在Windows 11上触发。本文将分析在当前安全防护不断完善的背景下,攻击者如何继续利用此类漏洞。
漏洞背景
0day漏洞指尚未公开且未被修复的安全漏洞,类似于金融市场的T+0交易概念。此类漏洞一旦被发现可能会在未被察觉的情况下被恶意利用,造成巨大危害。
本次发现的Windows系统0day漏洞可使攻击者获取系统完全控制权。这可能导致个人信息泄露、系统崩溃、数据丢失、财产损失等严重后果。从Web3角度看,可能造成私钥被盗、数字资产被转移,甚至影响整个基于Web2基础设施的Web3生态。
补丁分析
分析补丁代码发现,问题出在对象引用计数的多次处理。通过查看早期源码注释可知,以前的代码只锁定了窗口对象,而未锁定窗口中的菜单对象,可能导致菜单对象被错误引用。
漏洞复现
通过分析漏洞函数上下文,发现传入xxxEnableMenuItem()的菜单通常已在上层函数被锁定。进一步分析发现,MenuItemState函数返回的菜单可能是窗口主菜单,也可能是子菜单或子子菜单。
为触发漏洞,构造了一个特殊的四层菜单结构,并设置了以下特征:
在xxxRedrawTitle返回用户层时,删除菜单C和B的引用关系并释放菜单C。这样在xxxEnableMenuItem函数返回点时,即将引用的菜单C对象已失效。
漏洞利用
漏洞利用主要考虑两个方向:
执行shellcode代码:参考早期CVE-2017-0263等漏洞,但在高版本Windows中可能面临入口点和SMEP等安全机制问题。
利用读写原语修改token地址:近年来有多个公开exp可参考,对桌面堆内存布局和读写原语具有通用性。关键是分析如何在UAF内存重用时首次控制cbwndextra为特大值。
本次利用采用第二种方案,将整个过程分为两步:
首次数据写入
漏洞触发后,系统可能在MNGetPopupFromMenu()和xxxMNUpdateShownMenu()中错误使用被控制的窗口对象数据。我们使用窗口类WNDClass中的窗口名称对象占用释放的菜单对象。
关键是找到一个可由我们构建的地址结构中能任意写入数据的位置,哪怕只有一个字节。最终选择了xxxRedrawWindow函数中的方案,通过布局内存控制前一个对象的内存数据来通过函数中的对象标志判断。
稳定的内存布局
设计至少三个连续的0x250字节HWND对象,释放中间一个并用HWNDClass对象占用。前一个HWND对象尾部数据用于通过xxxRedrawWindow中的标志检验,后一个HWND对象的菜单对象和HWNDClass对象用作最终读写原语媒介。
通过堆内存中泄露的内核句柄地址来精确判断申请的窗口对象是否按预期顺序排列。
读写原语
任意读原语使用GetMenuBarInfo(),任意写原语使用SetClassLongPtr()。除替换TOKEN的写入外,其他写入都利用第一个窗口对象的class对象使用偏移来写入。
总结
win32k漏洞历史悠久,但微软正在尝试用Rust重构相关代码,未来新系统中此类漏洞可能被杜绝。
该漏洞利用过程相对简单,主要难点在于如何控制首次写入。严重依赖桌面堆句柄地址泄露,这仍是老旧系统的安全隐患。
该漏洞的发现可能得益于更完善的代码覆盖率检测。
对于漏洞利用检测,除关注触发函数关键点外,还应关注异常的内存布局和窗口数据偏移读写。