Security Research

[Paul Makowski]

Hello,
We're several students taking a browser security course with Collin Jackson.  The course involves a research component for which Collin suggested that we take a look at Web Intents.  We've come across a few items that we think might be of interest, but we're sure you know better than us.  We've looked through this Google Group for references to the following and haven't seen any direct coverage; our apologies if we missed something that has covered these.  Also, we apologize in advance for the super long email.

Any feedback you could give would be much appreciated. Thanks!


1) Intent Denial of Service:

• Description:  An attacker owning attacker.com who convinces a victim to visit attacker.com can consume and free space almost arbitrarily in the victim's UA localStorage for webintents.org.  This can be (ab)used to prevent additional Intent registration (for example by competing websites) or to prevent Web Intents from working at all (since a startActivity() call relies on the ability to write to webintents.org localStorage).  The below PoC will cause a complete Web Intents denial of service on Chrome 15.0.874.106 m; a more intelligent PoC would leave enough space for startActivity() calls to succeed but cause competitor registrations to fail.  Space may be "freed" by registering an large Intent (say, several MB) and then overwriting this Intent with a smaller one.
  
• PoC (tested on Chrome 15.0.874.106 m)
• visit: http://www.andrew.cmu.edu/user/jkallahe/denialofservice.html
  
• visit: http://examples.webintents.org/intents/pick/index.html
  
• click: Pick an Image
• effect: no Intents are listed
• expected: the Cat Image Picker and Google Image Picker Intents are listed
• Possible Solution: require user approval for Intent registration.
  

2) Reflective Content Injection Allows for Persistent Intent Overwrite:

• Description: This potential problem appears to be by design for the most part.  A vulnerability that allows an attacker to inject arbitrary content in another Origin could be leveraged to cause an Intent registration (or overwrite) on the victim Origin.  The barrier to entry here would be lower than XSS for sites that legitimately include the Web Intents JS shim.  For example, if a victim site has a naive filter for "script", this would not hinder the injection of an Intent tag.  Obviously sites that do not include the JS shim legitimately would need to be vulnerable to proper XSS.  However, even if this XSS vuln is only reflective, causing an Intent overwrite via reflected XSS would allow an attacker to persist an Intent overwrite until the victim user visited the previously XSSed Origin without the added reflected XSS. 
  
• So what?: We believe that Intent overwrite might be an issue for two primary reasons:
• An Intent whose legitimate href is HTTPS could be overwritten by the attacker to an HTTP destination within the same Origin.  This is interesting to a network attacker.
• An Intent's href can be overwritten to point to a page under any Origin, including one under the attacker's control.  This is more noisy from the attacker's perspective because the UI would display the new URL when this overwritten Intent was chosen.  This might be interesting to a web attacker who wishes to go phishing.
• Possible Solution: require user approval for Intent registration.

3) Intents Cannot be Registered Over HTTPS:

• Description: If we're not mistaken, it's not possible to include the current Web Intents JS shim over SSL.  This implies that any network attacker has full read/write privileges to the Web Intents localStorage, since a network attacker can inject arbitrary script purporting to come from http://webintents.org.  In addition, serving the WI JS shim over SSL does not fix this issue on IE8, since IE8 does not distinguish localStorage based on protocol (http://webintents.org and https://webintents.org share a localStorage bucket in IE8).
  
• So what?: A network attacker can leverage this read/write access to the webintents.org localStorage to cause an otherwise secure WI scheme to become a mixed-encryption scenario.
• Consider the following:
  
• http://picasa.com/album.html attempts to register an Intent for sharing images at https://picasa.com/share.html (SSL)
• The network attacker modifies either http://picasa.com/album.html's page or the JS shim in transit and causes the Intent to instead be registered for http://picasa.com/share.html (non-SSL).  Picasa is not aware that this has happened.
• https://facebook.com/postimage.html (SSL) fires the 'share' action of type 'images' and wants to maintain the confidentiality of any incoming image retrieved via an Intent.  Facebook is doing its part by serving over SSL; the Intent handlers must also do their part by serving over SSL.
• The victim clicks the Picasa Intent handler option.
• The victim is served with an insecure page, http://picasa.com/share.html (non-SSL) whose content is chosen by the attacker.  This page iframes the Picasa API (SSL).  This page registers a callback function for receiving the postMessage() containing the secret image.
  
• The network attacker captures an embarrassing image of the victim at a Nickelback concert.
  
• This attack can be carried out in a much simpler manner as well, but requires the attacker to be active during Intent firing: the network attacker simply replaces the Intent choosing dialog (served from http://webintents.org/picker.html) with content of his/her choosing.  This dialog is also not served over SSL.
• Possible Solution: Serve the JS shim, the picker dialog and all supporting files over SSL.  Do not serve these files over unencrypted HTTP, since all browsers but IE8 that are capable of supporting Web Intents differentiate localStorage based on protocol.  Alternatively, serve over both SSL and unsecured HTTP and maintain a "secure" and an "insecure" Intent registry and let implementing sites decide.
  

Some other ideas:

• Allow Intent registering websites to specify under what account an Intent was registered and then present this information prominently to the user when they go to pick an Intent.  In Android Intents, if the user clicks Share With -> Gmail, then the Intent is sent to the Gmail app and the Gmail app then prompts the user regarding which account to use.  Since the barrier to entry for adding an account on Android is significantly higher than on the web, it might make sense to store account details at time of Intent registration so that an attacker cannot, say, login CSRF the victim into the attacker's account in the background prior to handing off to Gmail.
• If the JS shim is served over both SSL and unsecured HTTP, make it really obvious to the user which is which.  Any native implementation (e.g. Chrome extension) might want to put a lock next to securely registered Intents and present all Intents in the same dialog, for example.

Again, sorry for the long email.  And if you've gotten here, thanks for reading.

Looking forward to anything you have to say,
~ Paul, Jenna, & Amal

[Paul Kinlan]

Hi,

Thank you for this thorough research.

1) Yes, I agree.  Approval is a currently open bug and will be addressed very very soon.

2) Yes, I agree.  I will raise an issue for re-registration and also ensure that the change of href is on the same origin.
3) https:  again, I defiantly agree, we are just porting to the appengine and will use SSL there and at the same time I am planning on forcing https for all requests.

3b) secure registry.  This is where it might differ from the native implementation.  We should discuss this more on this group.

P

--
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5

G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

[Paul Kinlan]

Hi,

I have logged these issues in the github issue tracker and added a new label "security".

https://github.com/PaulKinlan/WebIntents/issues?labels=Security&sort=created&direction=desc&state=open&page=1

I would encourage you, to log issues you find there and also report them here as well :)

Thanks again for the feedback, we really appreciate it.

P

[Greg Billock]

Yes. Thanks for all your work. We're currently working on an implementation of this prototype in the Chrome browser. Some of these concerns are relevant there; others apply only to the shim JS library. We definitely have user approval for intent service registration, but there's a tradeoff between providing the user a lot of unactionable information (i.e. how much space will be occupied) and just suppressing DoS-style or other malware type registrations.

In browser implementations, all intent data transfer happens strictly locally. Even with the shim, there's only interaction with the local storage. Still, though, loading the shim ought to happen over https for https usage (and arguably for other usage as well...)

In-browser implementations of the picker dialog will use a spoof-proof presentation. The pop-up implementation in the shim is about all you can do from javascript. 

If you're interested in reviewing the browser implementation, we're not quite ready to publish at-home build instructions. (There's a couple prerequisites that need to land first.) It'd be great to get another look at that as well.

-Greg

[Amal Krishnan]

Hi Greg,

We'd love to take a look at the browser implementation. Could you send instructions on building the prototype implementation?

Thanks,

~Amal

[James Hawkins]

Hey Amal,

We're working to write up the necessary steps to build Web Intents
into Chrome.  It's somewhat complicated since one has to pull in our
github branch of WebKit (which has our not-committed-to-WebKit-proper
code) as well as patch in an outstanding CL that should be committed
soon.

Once we get that all straightened out, we'll get back to you.

Thanks,
James

[Greg Billock]

Here are the instructions:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi/building-web-intents

Let me know if you have any problems with them. The branch maintenance is currently demand-driven, and so can lapse at times. :-)

[Paul Makowski]

I'm trying to build Chromium with the modified WebKit as per the linked instructions.  I'm build on x86_64 machine and chose to not include files necessary for 32bit compilation when I ran install-build-deps.sh (although I doubt this has any significance).  In the final step of the linked instructions, when running 'make chrome', I get the following:

In file included from chrome/renderer/chrome_render_view_observer.cc:30:0:
-- snip --
 CXX(target) out/Debug/obj.target/renderer/chrome/renderer/chrome_ppb_pdf_impl.o
  CXX(target) out/Debug/obj.target/renderer/chrome/renderer/chrome_render_process_observer.o
  CXX(target) out/Debug/obj.target/renderer/chrome/renderer/chrome_render_view_observer.o
In file included from chrome/renderer/chrome_render_view_observer.cc:30:0:
./chrome/renderer/webview_color_overlay.h:12:77: fatal error: third_party/WebKit/Source/WebKit/chromium/public/WebPageOverlay.h: No such file or directory
compilation terminated.
make: *** [out/Debug/obj.target/renderer/chrome/renderer/chrome_render_view_observer.o] Error 1

That file does not appear to be in the modified Web-Intents-modified WebKit branch.  The file is in the official WebKit repo. I ran the following to get the modified WebKit folder:
rm -rf third_party/WebKit
git clone --depth 1 git://github.com/gregbillock/webkit.git third_party/WebKit

My .gclient:
$ cat .gclient
solutions = [
  { "name"        : "src",
    "url"         : "http://src.chromium.org/svn/trunk/src",
    "deps_file"   : "DEPS",
    "managed"     : True,
    "custom_deps" : {
"src/third_party/WebKit/LayoutTests": None,

"src/chrome/tools/test/reference_build/chrome": None,
"src/chrome_frame/tools/test/reference_build/chrome": None,
"src/chrome/tools/test/reference_build/chrome_linux": None,
"src/chrome/tools/test/reference_build/chrome_mac": None,

    "src/third_party/WebKit/Source": None,
    "src/third_party/WebKit/Tools/Scripts": None,                    "src/third_party/WebKit/Tools/DumpRenderTree": None,
    "src/third_party/WebKit/Tools/TestWebKitAPI": None,
    "src/third_party/WebKit/Tools": None,
    "src/third_party/WebKit/WebKitLibraries": None,

    },
"safesync_url": "http://chromium-status.appspot.com/lkgr",
  },
]

The .gclient file was customized with a combination of excluded dirs, as mentioned here: https://sites.google.com/a/chromium.org/dev/developers/design-documents/webintentsapi/building-web-intents and here: http://code.google.com/p/chromium/wiki/UsingGit#Getting_the_code

Any ideas?  As far as I can tell, a clean pull via: git clone --depth 1 git://github.com/gregbillock/webkit.git third_party/WebKit does not compile.

Thanks for the help!

--
Sent from my Binford 6100

[Greg Billock]

This is probably an out-of-sync issue with tip-of-tree Chromium and
the webkit patch. We maintain this patch manually (and right now, as
we're patching, a bit irregularly). You ought to be able to do the
repair step in the doc to forward-migrate the webkit patch, but we're
in a kind of halfway-migrated state right now. I'm hoping to stabilize
it this coming week.

Thanks for your interest! Please let me know if you have any other questions.

-Greg