Difference between revisions of "Trash:Talk:Internet Browser"
| Line 9: | Line 9: | ||
I don't think this is exploitable in any way. To me, seems more like NULL pointer dereferencing. Here's my full theory, may be wrong tho: | I don't think this is exploitable in any way. To me, seems more like NULL pointer dereferencing. Here's my full theory, may be wrong tho: | ||
* the Javascript engine doesn't allocate memory for strings that are too long, but still keeps track of their length. (try generating a 2^31 characters long string, alert()'ing it shows an empty alert, however its length returns the expected value) | * the Javascript engine doesn't allocate memory for strings that are too long, but still keeps track of their length. (try generating a 2^31 characters long string, alert()'ing it shows an empty alert, however its length returns the expected value) | ||
| − | * such strings point to NULL instead of pointing to a memory buffer with characters. Their size is checked before trying to read them. | + | * such strings point to NULL instead of pointing to a memory buffer with characters. Their size is checked before trying to read them to display them in an alert. |
* now, if you generate a 2^32 string, the length of the string is 0x100000000 characters. This value gets cut off to zero because it doesn't fit in a 32bit integer. Therefore the length property of the string is zero. | * now, if you generate a 2^32 string, the length of the string is 0x100000000 characters. This value gets cut off to zero because it doesn't fit in a 32bit integer. Therefore the length property of the string is zero. | ||
* when trying to alert() this string, the security check described above does infact "0 < maxlength", so the string is considered short enough to be displayed. However, since it was made from strings being already too large, its pointer is NULL. | * when trying to alert() this string, the security check described above does infact "0 < maxlength", so the string is considered short enough to be displayed. However, since it was made from strings being already too large, its pointer is NULL. | ||
Revision as of 01:40, 13 August 2011
I have created a simple page that when opened in the browser freezes the 3DS system. I assume that too much memory is allocated to the JavaScript engine. This freeze can only be fixed by turning the system off and on again, but the communication switch works during this freeze. This is the page: https://dl-web.dropbox.com/get/Public/alerttest.html?w=88d076e5 R4wrz0rz0r 14:57, 20 June 2011 (CEST) I cannot access your page.you should make a public link from dropbox menu.
Sorry, I thought putting it in the Public folder would just make it work: http://dl.dropbox.com/u/18757478/alerttest.html R4wrz0rz0r 00:56, 21 June 2011 (CEST)
I think it is not so easy because this browser using Apple Webkit.
I don't think this is exploitable in any way. To me, seems more like NULL pointer dereferencing. Here's my full theory, may be wrong tho:
- the Javascript engine doesn't allocate memory for strings that are too long, but still keeps track of their length. (try generating a 2^31 characters long string, alert()'ing it shows an empty alert, however its length returns the expected value)
- such strings point to NULL instead of pointing to a memory buffer with characters. Their size is checked before trying to read them to display them in an alert.
- now, if you generate a 2^32 string, the length of the string is 0x100000000 characters. This value gets cut off to zero because it doesn't fit in a 32bit integer. Therefore the length property of the string is zero.
- when trying to alert() this string, the security check described above does infact "0 < maxlength", so the string is considered short enough to be displayed. However, since it was made from strings being already too large, its pointer is NULL.
- the browser tries to read from NULL, causing an exception. Probably said exception would trigger special stuff on dev/debug units, but was set to just enter an endless loop on retail units.
Long story short, nothing gets overwritten. Just an attempt at using a NULL pointer. This is only a theory though, I may be wrong. --Luigi2us 01:40, 13 August 2011 (CEST)