4 ms·

A few years ago, I built a platform for a client that allowed his customers to show a "Text Me" widget on their websites; the software handled all of the SMS /

A few years ago, I built a platform for a client that allowed his customers to show a "Text Me" widget on their websites; the software handled all of the SMS / messaging and basically substituted conventional contact form or Intercom integration. His customers used Google AdSense, who started blocking them until they removed the widget. The reason? This widget used an Iframe postMessage, but appropriately specified the singular sandboxed domain. As expected, we never were able to speak with a human at Google- they just sent my clients customers intimidating emails about a security flaw on their websites. Seeing Google abuse the postMessage API with a wildcard argument after this fiasco is maddening! If only they were held to their own arbitrary and vague standards.

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.

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.