Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bypass 003: Recursive eval #14

Closed
kumavis opened this issue Nov 24, 2013 · 3 comments
Closed

Bypass 003: Recursive eval #14

kumavis opened this issue Nov 24, 2013 · 3 comments

Comments

@kumavis
Copy link
Contributor

kumavis commented Nov 24, 2013

Heh, hunting these down sure is fun.

eval('this')
//=> undefined
eval('eval')('this')
//=> [object Window]

http://natevw.github.io/evel/challenge.html#eval('eval')('this')

@kumavis
Copy link
Contributor Author

kumavis commented Nov 24, 2013

the "use strict" directive ironically screws us here, blocking us from overwriting eval
This error is thrown "SyntaxError: Parameter name eval or arguments is not allowed in strict mode"

@kumavis
Copy link
Contributor Author

kumavis commented Nov 24, 2013

Hmmm, this is a tough one

@natevw natevw closed this as completed in 25f1a43 Nov 24, 2013
natevw added a commit that referenced this issue Nov 24, 2013
Plug security holes - Fixes #10 Fixes #11 Fixes #14
@natevw
Copy link
Owner

natevw commented Nov 25, 2013

Confirmed that this was always an issue (since 43353b2 anyway) and is still fixed after my latest cleanup. Surprised I missed this originally.

What was happening here I think is explained by MDN's strict mode documentation:

Relatedly, if the function eval is invoked by an expression of the form eval(...) in strict mode code, the code will be evaluated as strict mode code. The code may explicitly invoke strict mode, but it's unnecessary to do so.

This bypass does the opposite: by invoking eval in a different form it avoids strict mode, which is a big no-no for our purposes as you demonstrated. You can see this also via function () { var e = eval; return e('this'); }().

So I think replacing _gObj.eval with evel is indeed the only mitigation, which is fine except it means the real eval might not be useable to fix #12 as I'd hoped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants