4 ms·
I wonder how they persist the cached code, and if it is signed etc. Seems like it could be an attack vector if it was altered on the filesystem or something lik
by bcg1 12y ago
I wonder how they persist the cached code, and if it is signed etc. Seems like it could be an attack vector if it was altered on the filesystem or something like that.
I'm sure they thought of that, so I'm just curious. I suppose I could look through the Chromium source but I'm probably not actually smart enough to figure it out.
- ciupicri 12y agoIf someone else has write access to the your filesystem, you're already screwed.
- vidarh 12y agoWell, sort of, but it's not that simple. Let's say they write the cached data to $somedir/jitcache, and they, say expose some other API that indirectly allows you to store data at $somedir/foobar. If they fumble checks in this other API so you can manage to write arbitrary data to $somedir/jitcache instead of $somedir/foobar, an attacker suddenly has a powerful tool to escape the JS sandbox even if the flaw didn't allow them to write outside of $somedir. I'm not suggesting it's likely that this will be an issue, but it's a legitimate question to ask, as there's a long history of people managing to leverage a combination of flaws allowing them to write in a limited set of locations with different flaws allowing them trick some tool into executing what they manage to get written to disk.
- seba_dos1 12y ago"so you can manage to write arbitrary data to $somedir/jitcache instead of $somedir/foobar" That's already escaping from sandbox which most likely would cause much more troubles. In this way we can worry about absolutely anything ;)