该漏洞于上周末前辈一个叫做Andris Atteka的家伙发现,他在博客中讲述了程序中的错误,并提交了漏洞报告如下。
如果你给某人发送URL:`http://a/%%30%30`,这会使他的 Chrome 浏览器或 Gtalk 网页版崩溃。
——mdowd(@mdowd)2015年9月20日
我们已经在OS X El Capitan和Windows 10上的Chrome 45.0.2454.93版本分别进行了测试,结果显示都会受影响。Chromebooks,还有基于Chromium 45的Opera 32.0也会被这种URL搞崩溃。似乎只有安卓上的Chrome浏览器没事。
```
http://a/%%30%30
file://a/%%30%30
```
作为触发漏洞载荷的时候直接在地址栏输入载荷也会使浏览器崩溃, 而`http://a/%%300`则只有在html标签中的href里会触发漏洞
Atteka 在博客中还写到:“不幸的是,我没有得到任何报酬,好像就只有这么一个漏洞似的,不过,谷歌总是这样,做个安全的软件比发现软件其中的问题还难。”
更酷的是,这个漏洞会触发一个致命的异常(一个SIGTRAP),而不是通常的内存访问冲突错误导致的缓冲区溢出,堆损坏,或其他类似的发布中代码中产生的。这意味着可执行文件中的某部分跑到了程序员从没想到普通用户会点击的地方。事实证明,代码中的错误真够古老的。
这是OS X中的崩溃信息:
```
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread
0 com.google.Chrome.framework 0x0000000102b18a45 0x102500000 + 6392389
1 com.google.Chrome.framework 0x0000000105900595 0x102500000 + 54527381
2 com.google.Chrome.framework 0x00000001059083d2 0x102500000 + 54559698
```
我们来详细解释一下:
URL结尾的%%30%30被换成%00 (0x30是'0'的ASCII码。%%300是原'%'、转换后的'0'、原'0'组成的字符串。放在一起就是'%00'。)这就在网址末端插入了一个空字节。
这个URL被GURLToDatabaseURL()传出,它会调用ReplaceComponents()。
这会导致URL再次被处理,打出空字节。从而被认为不应该出现在那里,然后被标记成无效。
由于期待URL仍旧有效,代码路径返回到GURLToDatabaseURL(),调用spec()。
但是意料之外的,这个URL是无效的,所以这个函数访问了一个DCHECK()。
当将鼠标悬停在该URL,一个被标记无效的网址上时,它将被发送到预期中的唯一有效网址——导致标签死掉。
全部评论 (1)