Huh? It's perfectly valid in theory for one piece of trusted JavaScript to download another from an insecure source and validate it before evalling it - the attack scenario is not the browser being compromised, it's the source delivering malicious code. (Whether this is really a useful thing to do compared to serving all the JS in one place is another question.)

Real systems that try to implement this scheme generally wind up implementing the misconception that everything that contributes to the JS runtime comes from discrete Javascript files.

Do you have a source?

I tried googling javascript runtime (primarily v8) exploitation and haven't been able to find any examples of this ever happening.

Edit: I'm not saying its not plausible, but wouldn't it require root/user access? What benefit would it provide over other type of attacks with that level of access? Just because there's no browser tools to check for it?

This looks like a good read:

http://www.adambarth.com/papers/2009/barth-weinberger-song.p... Cross-Origin JavaScript Capability Leaks: Detection, Exploitation, and Defense

Although these vulnerabilities are imple- mentation errors in WebKit, the presence of the bugs illustrates the fragility of the general architec- ture. (Other browsers have historically had similar vulnerabilities [17, 18, 19].) We detail these vulner- abilities and construct proof-of-concept exploits to demonstrate how an attacker can leverage a leaked JavaScript pointer to inject a malicious script into an honest security origin.

Thanks I'll check it out, but I thought that tptacek was talking about manipulation of JS runtimes instead of exploitations of XSS bugs in webkit.

That's the thing about Javascript. The tiniest little XSS or subtle origin violation results in the entire browser app being 100% 'pwned' (to use the technical term).

The pwnage can even persist into the future for that user when you consider the ability of browsers to cache content and HTML5's data store.

Are you implying that they overlook other js contexts like onload tag attributes and such?

I get what you're driving at, but can't infer what you're conspicuously not explaining in full.

agreed, doing aes-256-cbc with a MAC is not exactly the first thing that comes to mind when it's a clear case for using a pbkdf.

you can probably drive a nail with a screwdriver handle if you try hard enough.

Not following how PBKDFx and CBC-MAC are comparable primitives.

I think he's confusing the key-derivation function this article talks about for your "master key" with the MAC-in-JS this particular thread is discussing.

i wasn't suggesting that they were comparable, rather that in mega's system a pbkdf makes more sense where they chose to use cbc-mac.

without going back and looking at the mega js, i recall it working as follows

password --> CBC-MAC --> master key --> decrypt RSA private key with derived master key

if you're deriving a key from a password, seems to make sense to use a password-based key derivation function.