4 ms·

Myeah. Here is another example of Google misunderstanding postMessage and mistaking a vulnerability in a website for a vulnerability in a competing "Chromodo" b

by twiss 6y ago

Myeah. Here is another example of Google misunderstanding postMessage and mistaking a vulnerability in a website for a vulnerability in a competing "Chromodo" browser, and making a big fuss about it: https://code.google.com/p/google-security-research/issues/detail?id=704 https://code.google.com/p/google-security-research/issues/de... (https://news.ycombinator.com/item?id=11023584 https://news.ycombinator.com/item?id=11023584)

Thorrez 6y ago
It doesn't look like that to me. There's a exploit demo here[1]. If the exploit worked in Chrome or Firefox as well as Chromodo, that would clearly indicate the problem is with the website, not with Chromodo. I find it hard to believe that no one at Google or Comodo would test the exploit page in Chrome or Firefox. There's discussion on the original bug and here[2] that Comodo did push out a fix, and it sure sounds like that was a fix to Chromodo. Secondly, looking at the exploit demo, it looks like it does 2 postMessage()s, once in each direction, both using execCode. If it was a vulnerability purely in https://ssl.comodo.com https://ssl.comodo.com the 2nd postMessage() looks like it would fail, because there isn't any code around to receive it. Thirdly, looking at the exploit demo, it has a text box with which you can specify which site you want to attack. So you could change that to https://google.com https://google.com or https://news.ycombinator.com https://news.ycombinator.com . If the exploit only worked against a single site, it wouldn't make sense to provide a text box allowing you to change which site to attack. Taviso's description is a bit misleading. It doesn't sound like the action that Comodo took is to directly disable the same origin policy, but rather to provide an API with which attackers can bypass the same origin policy. From a security perspective that does effectively disable the same origin policy, but from an attack understanding point of view, it's a bit different. Full disclosure, I work at Google, but not on Project Zero. [1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe... [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=713 https://bugs.chromium.org/p/project-zero/issues/detail?id=71...
- twiss 6y ago
  I see, fair enough. Thanks for the explanation.
geofft 6y ago
> Apparently https://ssl.comodo.com/ https://ssl.comodo.com/ used to then proceed to execute that code. However, this is not a vulnerability in the browser, but in that website. Am I missing something? Was Chromodo breaking the `messageEvent.origin` property, breaking same-origin checks in JavaScript? Seems far-fetched. I believe it's neither of these - I think the claim being made is that Chromodo installs a custom event listener for MessageEvents in all websites, which exposes a handful of APIs, including "execCode" and "callOuterFunction". If you look at the sample exploit (https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe...), while it defaults to ssl.comodo.com, you can specify an arbitrary website. (Also, if this were indeed a website bug, this would have been reproducible in normal browsers.) We would need to find a vulnerable version of the Chromodo browser to confirm this.

by twiss 6y ago

Thorrez 6y ago

It doesn't look like that to me. There's a exploit demo here[1]. If the exploit worked in Chrome or Firefox as well as Chromodo, that would clearly indicate the problem is with the website, not with Chromodo. I find it hard to believe that no one at Google or Comodo would test the exploit page in Chrome or Firefox. There's discussion on the original bug and here[2] that Comodo did push out a fix, and it sure sounds like that was a fix to Chromodo. Secondly, looking at the exploit demo, it looks like it does 2 postMessage()s, once in each direction, both using execCode. If it was a vulnerability purely in https://ssl.comodo.com https://ssl.comodo.com the 2nd postMessage() looks like it would fail, because there isn't any code around to receive it. Thirdly, looking at the exploit demo, it has a text box with which you can specify which site you want to attack. So you could change that to https://google.com https://google.com or https://news.ycombinator.com https://news.ycombinator.com . If the exploit only worked against a single site, it wouldn't make sense to provide a text box allowing you to change which site to attack. Taviso's description is a bit misleading. It doesn't sound like the action that Comodo took is to directly disable the same origin policy, but rather to provide an API with which attackers can bypass the same origin policy. From a security perspective that does effectively disable the same origin policy, but from an attack understanding point of view, it's a bit different. Full disclosure, I work at Google, but not on Project Zero. [1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe... [2] https://bugs.chromium.org/p/project-zero/issues/detail?id=713 https://bugs.chromium.org/p/project-zero/issues/detail?id=71...

twiss 6y ago
I see, fair enough. Thanks for the explanation.

geofft 6y ago

> Apparently https://ssl.comodo.com/ https://ssl.comodo.com/ used to then proceed to execute that code. However, this is not a vulnerability in the browser, but in that website. Am I missing something? Was Chromodo breaking the `messageEvent.origin` property, breaking same-origin checks in JavaScript? Seems far-fetched. I believe it's neither of these - I think the claim being made is that Chromodo installs a custom event listener for MessageEvents in all websites, which exposes a handful of APIs, including "execCode" and "callOuterFunction". If you look at the sample exploit (https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=225988 https://bugs.chromium.org/p/project-zero/issues/attachmentTe...), while it defaults to ssl.comodo.com, you can specify an arbitrary website. (Also, if this were indeed a website bug, this would have been reproducible in normal browsers.) We would need to find a vulnerable version of the Chromodo browser to confirm this.