4 ms·

If you aren't familiar with SOP, this is about the worst "stupid web vuln" that can happen. SOP is the glue that kind of almost makes the web secure. The attack

If you aren't familiar with SOP, this is about the worst "stupid web vuln" that can happen. SOP is the glue that kind of almost makes the web secure. The attack DOES work if X-Frame-Options is enabled (thanks joev. The msfmodule says so clearly). ALL sites with or without XFrameOptions can be loaded in an iframe, and sent to a bad guy. If you would like to test on your device/browser, you can on ejj.io/SOP.php . If you click on the button and you see an alert box, you're vulnerable (I doubt many on HN will....) Many other browser's also seem to be vulnerable. So if you use something else best be safe and check yourself

yeahforbes 12y ago
I have a browser called InBrowser and it gives an alert on your test page. Maybe it wraps AOSP? I don't have "Browser" in my list of apps though, it came with Chrome instead and I installed InBrowser myself. (Android 4.1.2)
- TD-Linux 12y ago
  Almost all third-party browsers on the Play Store wrap the Android WebView, which is vulnerable. You'll need to use a browser that includes its own rendering engine, such as Firefox, to remain secure.
  - sucramb 12y ago
    The Android WebView uses since quite some time the same rendering and javascript engines as Chrome. Thus I would expect third party browsers to be no more vulnerable with regard to this bug than Chrome. Edit: since 4.4 [https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview]
- tompod 12y ago
  Hi YeahForbes, TomPod, the creators of InBrowser, here. We're unable to reproduce this error on a oneplus and a HTC M8 running the latest version of InBrowser. But rest assured, we'll check this with our suite of devices and Android version during the day. Since version 2.11 (43), 2014-03-09 we limit the usage of JavaScript: due to another bug in Android. Hopefully it'll fix this issue as well. So please make sure that you're on latest version from Google Play. If we can fix this on our side we'll push a fix asap. If not, we unfortunately need to wait for Google to address this. We'll post any updates on this issue at @tompodapps. Thanks for reporting it!
joev_ 12y ago
Actually X-Frame-Options does not save you here. There is a BYPASS_XFO datastore option in the module that turns this into a one-click exploit. This allows the attack to work against sites with the XFO header.
- steakejjs 12y ago
  Absolutely critical to know. Thanks joev_. I see that now after reading the msfmodule. This is a good one!
gcb0 12y ago
good old blacklist instead of whitelist. why forbid javascript: and some other thing that you know know, if you know for sure you only want http or https? always allow what you know for sure how to handle instead of denying what you think you know that you don't want.
- GICodeWarrior 12y ago
  While good advice, I suspect that isn't what's going on. My guess would be that the URL is being validated with code which relies on null-terminated strings, and it's being processed/executed with code that uses a separate length value. The empty string "" will pass a same-origin check as it refers to the current page. "\0javascript:alert()" looks like the empty string to validation code expecting null-terminated strings. However, it's a valid URL and is executed as JavaScript by code that knows the true length. One easy way this could happen is if the same-origin check happens in C++ (eg. WebKit) and the URL fetch happens in Java. The same problem can happen in reverse and has before. Java had a file path vulnerability where Java code would see the full path and the OS calls Java passed to would only process up to the first null. This opened up bypasses in application logic designed to validate paths.
  - userbinator 12y ago
    However, it's a valid URL I doubt "\0javascript" is a valid URI scheme since they must begin with a letter, and any code that uses 0-terminated strings would just see it as an empty string. The fact that the \0 somehow seems to be ignored completely is most disturbing. Edit: I double-checked the spec ( http://www.w3.org/TR/html5/browsers.html#dom-open http://www.w3.org/TR/html5/browsers.html#dom-open ) just to make sure there's no weird "skip nulls" behaviour, and there isn't.
    - GICodeWarrior 12y ago
      This is one of those cases where browsers are different from the spec. (BTW, the spec you are looking for is here https://url.spec.whatwg.org/ https://url.spec.whatwg.org/) It really depends on the browser. Here are a few test cases to consider. http://jsfiddle.net/8e525ne9/ http://jsfiddle.net/8e525ne9/ Leading nulls used to work in common browsers. Most recent browsers don't support it. However, most do continue to support fun things like newlines and tabs in the middle of URL schemes.
owenversteeg 12y ago
Clickable: http://ejj.io/SOP.php http://ejj.io/SOP.php
geographomics 12y ago
The alert did not appear on an Android 2.3 device (HTC Desire), or a 2.2 emulator (via BrowserStack.com) - not vulnerable, or not compatible with the exploit test?
- steakejjs 12y ago
  I would think this means you are not vulnerable. The js begins with a null byte and works on a lot of different versions. I think the vuln probably just had not been introduced at that time, but I obviously can't be certain without digging through the git log (and even then...all I can do is corroborate commits with release dates).
- ufmace 12y ago
  I tried it myself also a few minutes ago, on an old Droid Eris/HTC Hero (IIRC) running CM7, Android 2.3.2. It does do an odd double-loading thing, but it doesn't show the alert. Also, damn this thing is slow and tiny compared to my current phone. Tried again with a Galaxy Nexus on 4.3. Sure enough, it duplicates fine on the stock browser, and works correctly in Chrome.
- joev_ 12y ago
  I didn't test back this far; I should have, it's about 10% of android users. I tested back to 4.0 (not that 4.0-4.1.2 being vulnerable matters much, since you can get remote code execution easily through the addJavascriptInterface vulnerability). I tried out 2.1 in the emulator just now and got the same results as you, so it looks like 2.x is not affected by this.
AndrewOMartin 12y ago
What's the expected response when clicking the button in Chrome on Android 4.4.4? I'm on a Nexus 5, on 4.4.4 and I see an alert box in Chrome 37.0.2062.117.
- steakejjs 12y ago
  This is absolutely not the expected response, which is really odd. I am running android 4.4.4 on a nexus 5 on Chrome 37.0.2062.117 (it just so happens) and I don't see an alert box. Expected is no alert box
  - AndrewOMartin 12y ago
    I can no longer reproduce this on my Nexus 5. The first time I tried it (yesterday), I saw an empty alert box. The second time I tried it (today), the button pops in and out ineffectively.

yeahforbes 12y ago

I have a browser called InBrowser and it gives an alert on your test page. Maybe it wraps AOSP? I don't have "Browser" in my list of apps though, it came with Chrome instead and I installed InBrowser myself. (Android 4.1.2)

TD-Linux 12y ago
Almost all third-party browsers on the Play Store wrap the Android WebView, which is vulnerable. You'll need to use a browser that includes its own rendering engine, such as Firefox, to remain secure.
- sucramb 12y ago
  The Android WebView uses since quite some time the same rendering and javascript engines as Chrome. Thus I would expect third party browsers to be no more vulnerable with regard to this bug than Chrome. Edit: since 4.4 [https://developer.chrome.com/multidevice/webview/overview https://developer.chrome.com/multidevice/webview/overview]
tompod 12y ago
Hi YeahForbes, TomPod, the creators of InBrowser, here. We're unable to reproduce this error on a oneplus and a HTC M8 running the latest version of InBrowser. But rest assured, we'll check this with our suite of devices and Android version during the day. Since version 2.11 (43), 2014-03-09 we limit the usage of JavaScript: due to another bug in Android. Hopefully it'll fix this issue as well. So please make sure that you're on latest version from Google Play. If we can fix this on our side we'll push a fix asap. If not, we unfortunately need to wait for Google to address this. We'll post any updates on this issue at @tompodapps. Thanks for reporting it!

joev_ 12y ago

Actually X-Frame-Options does not save you here. There is a BYPASS_XFO datastore option in the module that turns this into a one-click exploit. This allows the attack to work against sites with the XFO header.

steakejjs 12y ago
Absolutely critical to know. Thanks joev_. I see that now after reading the msfmodule. This is a good one!

gcb0 12y ago

good old blacklist instead of whitelist. why forbid javascript: and some other thing that you know know, if you know for sure you only want http or https? always allow what you know for sure how to handle instead of denying what you think you know that you don't want.

GICodeWarrior 12y ago
While good advice, I suspect that isn't what's going on. My guess would be that the URL is being validated with code which relies on null-terminated strings, and it's being processed/executed with code that uses a separate length value. The empty string "" will pass a same-origin check as it refers to the current page. "\0javascript:alert()" looks like the empty string to validation code expecting null-terminated strings. However, it's a valid URL and is executed as JavaScript by code that knows the true length. One easy way this could happen is if the same-origin check happens in C++ (eg. WebKit) and the URL fetch happens in Java. The same problem can happen in reverse and has before. Java had a file path vulnerability where Java code would see the full path and the OS calls Java passed to would only process up to the first null. This opened up bypasses in application logic designed to validate paths.
- userbinator 12y ago
  However, it's a valid URL I doubt "\0javascript" is a valid URI scheme since they must begin with a letter, and any code that uses 0-terminated strings would just see it as an empty string. The fact that the \0 somehow seems to be ignored completely is most disturbing. Edit: I double-checked the spec ( http://www.w3.org/TR/html5/browsers.html#dom-open http://www.w3.org/TR/html5/browsers.html#dom-open ) just to make sure there's no weird "skip nulls" behaviour, and there isn't.
  - GICodeWarrior 12y ago
    This is one of those cases where browsers are different from the spec. (BTW, the spec you are looking for is here https://url.spec.whatwg.org/ https://url.spec.whatwg.org/) It really depends on the browser. Here are a few test cases to consider. http://jsfiddle.net/8e525ne9/ http://jsfiddle.net/8e525ne9/ Leading nulls used to work in common browsers. Most recent browsers don't support it. However, most do continue to support fun things like newlines and tabs in the middle of URL schemes.

owenversteeg 12y ago

Clickable: http://ejj.io/SOP.php http://ejj.io/SOP.php

geographomics 12y ago

The alert did not appear on an Android 2.3 device (HTC Desire), or a 2.2 emulator (via BrowserStack.com) - not vulnerable, or not compatible with the exploit test?

steakejjs 12y ago
I would think this means you are not vulnerable. The js begins with a null byte and works on a lot of different versions. I think the vuln probably just had not been introduced at that time, but I obviously can't be certain without digging through the git log (and even then...all I can do is corroborate commits with release dates).
ufmace 12y ago
I tried it myself also a few minutes ago, on an old Droid Eris/HTC Hero (IIRC) running CM7, Android 2.3.2. It does do an odd double-loading thing, but it doesn't show the alert. Also, damn this thing is slow and tiny compared to my current phone. Tried again with a Galaxy Nexus on 4.3. Sure enough, it duplicates fine on the stock browser, and works correctly in Chrome.
joev_ 12y ago
I didn't test back this far; I should have, it's about 10% of android users. I tested back to 4.0 (not that 4.0-4.1.2 being vulnerable matters much, since you can get remote code execution easily through the addJavascriptInterface vulnerability). I tried out 2.1 in the emulator just now and got the same results as you, so it looks like 2.x is not affected by this.

AndrewOMartin 12y ago

What's the expected response when clicking the button in Chrome on Android 4.4.4? I'm on a Nexus 5, on 4.4.4 and I see an alert box in Chrome 37.0.2062.117.

steakejjs 12y ago
This is absolutely not the expected response, which is really odd. I am running android 4.4.4 on a nexus 5 on Chrome 37.0.2062.117 (it just so happens) and I don't see an alert box. Expected is no alert box
- AndrewOMartin 12y ago
  I can no longer reproduce this on my Nexus 5. The first time I tried it (yesterday), I saw an empty alert box. The second time I tried it (today), the button pops in and out ineffectively.