search

asvd / jailed

execute untrusted code with custom permissions
MIT License
1k stars 69 forks source link

Jail break by anonymous function call #1

Closed tzik closed 9 years ago

tzik commented 9 years ago

On the online demo, 

  (function(){return this})().postMessage

returns the native one. I think this is an unintended leak of a dangerous object for the sandbox.

asvd commented 9 years ago

Thanks for the feedback.

What you did is obtained an access to the Worker's internal scope, now you can send messages to the main application. But the accessing the worker scope is not insecure, in fact that is the sandbox provided by the browser and reused by Jailed to protect the main application from being accessed by untrusted code.

The worst thing you can do in this case is closing the worker:

(function(){return this})().close();

or using a method provided by the Jailed library:

(function(){return this})().application.disconnect();

This is not dangerous, a plugin may kill itself if it wants ;-) The application will be notified and may restart a plugin in that case (try the last snippet in the console demo)

Normally an untrusted code running in a plugin created by Jailed library has full access to the worker's scope (particullary it may use postMessage(), but exported functions are designed to be a convenient replacement for that). The reason why I hid those properties in the demo is in that the Console is some kind of virtual environment for a user to evaluate custom JS on the fly. In this sence, the methods available to the worker are not related to the purpose of that application.

PS I have improved the disconnect handling by the console demo, thanks for pointing that out.

PPS Text selection was also re-enabled on the console, disabling it was a stupid idea :-)

tzik commented 9 years ago

I believe Worker is not intended to provide a sandbox...

Are you sure you don't mind the "jailed" script accesses any API in Worker? Even though it can't directly access to DOM, it can access any other, including IndexedDB, FileSystem, WebSocket and XMLHttpRequest. And even it may be able to access cookie via CORS XHR + withCredential flag. I feel it's still dangerous to execute untrusted code in that.

How about replacing that with