-
-
转载 短短一行URL能让你的chrome浏览器崩溃
-
发表于: 2015-9-26 08:08 1096
-
点击或仅仅滚动鼠标是怎么使浏览器崩溃的?
你可以用一个简单的短短一行URL使谷歌Chrome浏览器的最新版本崩溃。
只需滚动鼠标移到浏览器的一个页面上,然后从另一个应用程序,比如一个电子邮件客户端启动它,或者把它粘贴到地址栏,这些操作会使标签或者整个浏览器死掉。
这会是完美的捉弄朋友的方法,只需将其发送到他们电子邮件或短信。
该漏洞于上周末前辈一个叫做Andris Atteka的家伙发现,他在博客中讲述了程序中的错误,并提交了漏洞报告如下。
如果你给某人发送URL:https://t.co/vi0e10IEFH,这会使他的Chrome浏览器或Gtalk网页版崩溃。
——mdowd(@mdowd)2015年9月20日
以下是两种形式的URL截图——我们不会把它们以文字形式放进这篇文章中来的,因为那会使你的标签崩溃,如果你在用Chrome浏览器而且恰巧不小心把鼠标指针移到那里。那不会有好事发生的。
我们已经在OS X El Capitan和Windows 10上的Chrome 45.0.2454.93版本分别进行了测试,结果显示都会受影响。Chromebooks,还有基于Chromium 45的Opera 32.0也会被这种URL搞崩溃。似乎只有安卓上的Chrome浏览器没事。
http://a/%%300
file:///%%300
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结尾的%%300被换成%00 (0x30是'0'的ASCII码。%%300是原'%'、转换后的'0'、原'0'组成的字符串。放在一起就是'%00'。)这就在网址末端插入了一个空字节。
这个URL被GURLToDatabaseURL()传出,它会调用ReplaceComponents()。
这会导致URL再次被处理,打出空字节。从而被认为不应该出现在那里,然后被标记成无效。
由于期待URL仍旧有效,代码路径返回到GURLToDatabaseURL(),调用spec()。
但是意料之外的,这个URL是无效的,所以这个函数访问了一个DCHECK()。
当将鼠标悬停在该URL,一个被标记无效的网址上时,它将被发送到预期中的唯一有效网址——导致标签死掉。
关于开发人员如何计划来解决Chromium漏洞查找中的问题还会有更多的讨论。情况类似于6月份困扰Skype的那个问题。
“由于这个漏洞,会发生各种各样的崩溃。这是个烂摊子。”几个小时前Chromium项目成员叹气道。该团队正在研究解决方法,敬请关注。
.
你可以用一个简单的短短一行URL使谷歌Chrome浏览器的最新版本崩溃。
只需滚动鼠标移到浏览器的一个页面上,然后从另一个应用程序,比如一个电子邮件客户端启动它,或者把它粘贴到地址栏,这些操作会使标签或者整个浏览器死掉。
这会是完美的捉弄朋友的方法,只需将其发送到他们电子邮件或短信。
该漏洞于上周末前辈一个叫做Andris Atteka的家伙发现,他在博客中讲述了程序中的错误,并提交了漏洞报告如下。
如果你给某人发送URL:https://t.co/vi0e10IEFH,这会使他的Chrome浏览器或Gtalk网页版崩溃。
——mdowd(@mdowd)2015年9月20日
以下是两种形式的URL截图——我们不会把它们以文字形式放进这篇文章中来的,因为那会使你的标签崩溃,如果你在用Chrome浏览器而且恰巧不小心把鼠标指针移到那里。那不会有好事发生的。
我们已经在OS X El Capitan和Windows 10上的Chrome 45.0.2454.93版本分别进行了测试,结果显示都会受影响。Chromebooks,还有基于Chromium 45的Opera 32.0也会被这种URL搞崩溃。似乎只有安卓上的Chrome浏览器没事。
http://a/%%300
file:///%%300
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结尾的%%300被换成%00 (0x30是'0'的ASCII码。%%300是原'%'、转换后的'0'、原'0'组成的字符串。放在一起就是'%00'。)这就在网址末端插入了一个空字节。
这个URL被GURLToDatabaseURL()传出,它会调用ReplaceComponents()。
这会导致URL再次被处理,打出空字节。从而被认为不应该出现在那里,然后被标记成无效。
由于期待URL仍旧有效,代码路径返回到GURLToDatabaseURL(),调用spec()。
但是意料之外的,这个URL是无效的,所以这个函数访问了一个DCHECK()。
当将鼠标悬停在该URL,一个被标记无效的网址上时,它将被发送到预期中的唯一有效网址——导致标签死掉。
关于开发人员如何计划来解决Chromium漏洞查找中的问题还会有更多的讨论。情况类似于6月份困扰Skype的那个问题。
“由于这个漏洞,会发生各种各样的崩溃。这是个烂摊子。”几个小时前Chromium项目成员叹气道。该团队正在研究解决方法,敬请关注。
.
赞赏
看原图
赞赏
雪币:
留言: