The compressed address of the JavaScript double array is different by two times startup

[bb33bb]

Big bro , i think may be I am idiot or maybe i get another thing that when i start 2 times of chrome on linux ,the addr of map for double arr is diefferent.
i think i am using the official chrome , and look at the following flag:

Google Chrome	94.0.4606.61 (Official Build) unknown (64-bit)
Revision	418b78f5838ed0b1c69bb4e51ea0252171854915-refs/branch-heads/4606@{#1204}
OS	Linux
JavaScript	V8 9.4.146.16
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/94.0.4606.61 Safari/537.36
Command Line	./chrome --no-sandbox --js-flags=--expose-gc --allow-natives-syntax --user-data-dir=./userdata --enable-crashpad --flag-switches-begin --flag-switches-end http://127.0.0.1
Executable Path	/home/avboy/Desktop/chrome/chrome
Profile Path	/home/avboy/Desktop/chrome/userdata/Default

<script>
var x = [1.1,1.1,1.1];
%DebugPrint(x);
alert()
</script>

[bb33bb]

the d8 version of win (same to linux of your blog) is really true for the map address and exp is really so reliable , maybe 1 or 2 times trying is ok to pop calc in win10.

[m-y-mo]

Thanks for testing. I was using a local build for testing and have not tried it on the actual google chrome. Would you be able to try building revision c3f0a75 and see if that works? (See the README.md) One other thing that I noticed on the build that I tested is that when the js-flags are switched on, the exploit fails (probably due to --expose-gc more than anything, so that doesn't explain the map address either), but maybe its worth trying to not include the js-flags (which are not default anyway) With the other flags on, (i.e. ./chrome --user-data-dir=/tmp/abc --no-sandbox --enable-crashpad --flag-switches-begin --flag-switches-end), the exploit works on the build that I have. I'll try to get an old official version and take a look at it. Thanks.

[m-y-mo]

OK done some more testing on google chrome 95.0.4638.54 to test the map addr issue, using the official binary installed from google. This is the version and flag info:

Google Chrome | 95.0.4638.54 (Official Build) (64-bit)
-- | --
Revision | d31a821ec901f68d0d34ccdbaea45b4c86ce543e-refs/branch-heads/4638@{#871}
OS | Linux
JavaScript | V8 9.5.172.21
User agent | Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
Command Line | /usr/bin/google-chrome --js-flags=--allow-natives-syntax --user-data-dir=/tmp/abc --enable-crashpad --flag-switches-begin --flag-switches-end
Executable Path | /opt/google/chrome/google-chrome

The map addr seems stable at 0x082430e1 most of the time, although I do notice it being different once or twice out of more than 10 relaunches/different renderer processes. So this should not be a problem with the exploit because if the map addr is incorrect, then a restart of the renderer should most likely to give you back the stable map addr. I guess what you're seeing is the rare occasions where the map addr doesn't match, but if you launch/restart the renderer multiple times, the map addr should be the same most of the time.

[bb33bb]

Really well done and appretiate for your work !
And thanks a lot for your patients!!

[m-y-mo]

No worries, thank you very much for testing it, I'm glad that it works!

[m-y-mo]

Also when testing on a different version/revision on Linux, don't forget to change the variable wasmMemoryProtectionKeysOffset in chrome_poc_child.html, which is a fixed offset that depends on the binary itself.

[bb33bb]

OK and i think you are right.i will try again . And you are right, I only changed the map hash.