Comment by shawn | Hacker News Reader

Comment by shawn | Hacker News Reader

Built-in functions currently consume 700 KB in each Isolate (an Isolate roughly corresponds to a browser tab in Chrome). This is quite wasteful, and last year we began working on reducing this overhead. In V8 v6.4, we shipped lazy deserialization, ensuring that each Isolate only pays for the built-ins that it actually needs (but each Isolate still had its own copy).

Also known as Autoload. What’s old is new again... http://www.gnu.org/software/emacs/manual/html_node/elisp/Aut...

Embedded built-ins go one step further. An embedded built-in is shared by all Isolates, and embedded into the binary itself instead of copied onto the JavaScript heap. This means that built-ins exist in memory only once regardless of how many Isolates are running, an especially useful property now that Site Isolation has been enabled by default.

Inb4 security vuln in a builtin is used to pivot across tabs or reveal state in other tabs. Like, say, a timing attack on regex exec to reveal whether the word “Facebook” appears in some other tab. </baseless>

> Inb4 security vuln in a builtin is used to pivot across tabs or reveal state in other tabs.

Although I don't know all the internals of how chrome isolates tabs, I'm not sure how that's supposed to happen. If I understand the original approach correctly, it just means that the code is in the original binary, paged in once and using copy-on-write semantics while forking individual sandbox processes only exists as a single copy instead of multiple copies that would happen if the code somehow has to be prepared by "copying to the JS heap" of each individual sandbox process.

Yes, this is my understanding of the implementation.

Is this even possible?

Its just read-only machine code, theres no stack data for instance from the last executions that you can watch for.

Maybe only if you know when the code is being executed, in which register that particular builtin write the memory address of the payload, and then go for the payload on the heap to see what's there.

To know when the code will be executed you would need to watch for the VM loop and to when that particular builtin you are interested in its on the 'execution needle'.. But to get there you would first need to find a exploit, with arbitrary code execution, where you can upload your exploit payload to hook on the VM loop (and this sounds a lot of work to me).

(Not a Sec. guy myself, so genuinely curious how this could be done, but trying to figure out a way to exploit this, i kind of begin to see how it could be done)

Reply on news.ycombinator.com