On 04/18/2014 08:58 PM, Jonas Sicking wrote:
Another solution here would be if we added support for URLs that map
directly into indexedDB. See
http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0081.html
It seems like this could open new avenues for information leakage unless
URLs require JS code execution to bless them into validity using a
variant on createObjectURL or just the getURL your proposed bug magicked
into createURL/mapURL. For example...
Hypothetically, let's say I'm an email app with a predictable db schema;
messages are stored by the uniqueish "message-id"[1] header included
with every message and known to every recipient of that message. Let's
also say my authors didn't care about user privacy too much so they
display remote images/resources by default and don't bother sanitizing
them for this reason. I, hypothetical email app, do put that HTML
content in an sandboxed iframe that forbids script from running because
I'm not completely reckless. But I do keep the iframe in my origin
because in order for me to display embedded images in the e-mail which
I've saved to IndexedDB as Blobs, well, that's what I've got to do to
surface the Blobs or be able to manipulate/interact with the iframe's
HTML DOM at all after minting the iframe and its document.
And for the payoff: evil bad person formulates an HTML e-mail that
checks whether the user has received a message that definitely exists or
might exist by including resource references to the IndexedDB database
that impacts the timing of other external resources fetched by the
e-mail where the attacker controls the resources or can somehow observe
the timing that the resources are fetched. If the web platform in
question defers fetching resources until they can be displayed, the
failure to fetch a resource in a timely fashion can also produce
entropy. This probably does require the user to open the email,
although if the app tries to do any parsing of the email ahead of time
to generate snippets or detect links or phone numbers or package
delivery references or the like, no interaction would be required.
Such an attack would be a bit easier if the message the attacker is
looking for included an embedded Blob so it can be used to conditionally
take up document real-estate. But even use of an img tag in a way
that's expected to fail to load regardless of the presence of the
message would likely result in observable timing differences based on
our IndexedDB schema.
There may also be a class of vulnerabilities related to the use of
<form> elements, but that more definitely involves user interaction.
Note that the Gaia email app does not work like this hypothetical email app.
Andrew
1: Note that the message-id isn't intended to be unguessable, just not
collide with other messages. Many mail clients' generated id's are
likely to have much of their entropy come from the time at which they
were sent, so the brute forcing space is limited if you know around when
the message was sent.
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
