Hacking Restricted Webkit bug finder

[endoverend]

Very true...I remember Sony had their ninjas on ps3 hacking scenes and followed everything. One of them was an active user as well. If they patch, they patch. Whoever's on 5.3.2 is best to stay there. turn off wifi for now as this is scene is going to blow up soon. Last time a scene was this active was the LV0 leak on the ps3.

OMG, browser crashes aren't gigantic holes in the system. There's no reason to be so quiet about it. There are thousands of webkit holes and probably 99% of them are not exploitable. Who is it going to take to convince you about this?

 

[dojafoja]

That's not how it works. Just google the github webkit and find the beforeload-iframe-crash.html file, copy the contents into a blank txt file, change the extension to html, then load it up in a web server. If you don't know how to do something like this then maybe finding bugs in Wii U software isn't what you should be focusing on.

I think you quoted the wrong person lol. BTW during my tests, I found that some of the .html files rely on other .html files within the directory structure somewhere. Because of this you would want the entire directory present in the servers working directory so the html files can find their dependencies.

 

[Theeze]

OMG, browser crashes aren't gigantic holes in the system. There's no reason to be so quiet about it. There are thousands of webkit holes and probably 99% of them are not exploitable. Who is it going to take to convince you about this?

.I meant any bug/exploit, not just the webkit /browser bugs. No wonder the mods earlier went into full force...people need to take deep breaths and relax.

 

[dojafoja]

New version added with easy file hosting. Simply copy the layout test html file information from the results view, paste it into the hosting view, click host file. The server will place itself into the proper directory(so dependencies can still be found) and make a copy of the file and rename it to index.html. This way, just point your browser to your_local_ip_address:8000 and it will automatically load the index.html file. If no crash or buggy behaviour, find and host a different file and click refresh on the browser. In theory this could be done over and over and over. Some may argue that a full reboot is needed between tests to ensure a clean testing environment but I'm not sure how relevant that is to our case.

BTW there is no context menu on right click. To copy/paste just use the keyboard Ctrl-C/Ctrl-V

 

[dojafoja]

I really need some people to test the file hosting portion mostly on Windows(but Linux too although I believe it works fine on both). My tests were very limited. If someone is able to, test this extensively and report back.

 

[Marionumber1]

Found one at r169475. The browser freezes and locks up using the layout test at fast/events/beforeload-iframe-crash.html

Does it really? I'm pretty sure that's the one we already use. What version is your Wii U?

EDIT: Never mind, it is different.

 

[Deleted User]

I really need some people to test the file hosting portion mostly on Windows(but Linux too although I believe it works fine on both). My tests were very limited. If someone is able to, test this extensively and report back.

I think I can help you out. I remember using Webstarts.com to test the Wii U browser exploit.

 

[endoverend]

Does it really? I'm pretty sure that's the one we already use. What version is your Wii U?

EDIT: Never mind, it is different.

5.3.2. Latest FW always here. I don't think it's a use-after-free so it won't lead to much but give it a try.
Here's the HTML code if anyone wants it:

Spoiler

<iframe></iframe><object onbeforeload="crash()">
<script>
if (window.testRunner) {
testRunner.dumpAsText();
testRunner.waitUntilDone();
}
function crash() {
document.getElementsByTagName("iframe")[0].contentWindow.scrollX;
document.open();
}
document.body.offsetLeft;
setTimeout(function() {
document.close();
document.body.innerHTML = 'PASS if not crashed.';
testRunner.notifyDone();
}, 1);
</script>

 

[Deleted User]

5.3.2. Latest FW always here. I don't think it's a use-after-free so it won't lead to much but give it a try.
Here's the HTML code if anyone wants it:

Spoiler

<iframe></iframe><object onbeforeload="crash()">
<script>
if (window.testRunner) {
testRunner.dumpAsText();
testRunner.waitUntilDone();
}
function crash() {
document.getElementsByTagName("iframe")[0].contentWindow.scrollX;
document.open();
}
document.body.offsetLeft;
setTimeout(function() {
document.close();
document.body.innerHTML = 'PASS if not crashed.';
testRunner.notifyDone();
}, 1);
</script>

I tried it out, and it crashes as soon as I click the link. xD

 

[yahoo]

Found one at r169475. The browser freezes and locks up using the layout test at fast/events/beforeload-iframe-crash.html

It's funny how they fix, revert and then re-fix this issue: https://github.com/WebKit/webkit/commits/master/LayoutTests/fast/events/beforeload-iframe-crash.html
The commit description doesn't mention use-after-free, but we'll have to test it out:

This CL makes 'beforeload' event dispatching for plugins and iframes asynchronous

 

[IbbyPlays]

Is this crash exploitable, considering it crashes before loading the webpage (so it might not load out code) and the current exploit doesn't?

 

[IbbyPlays]

Also, two Q's
(1.) Python 2 or 3?
(2.) Do I need to have my copy of the webkit repo in the same directory as the rest of the bug-finder?

 

[Deleted User]

Is this crash exploitable, considering it crashes before loading the webpage (so it might not load out code) and the current exploit doesn't?

Also, two Q's
(1.) Python 2 or 3?
(2.) Do I need to have my copy of the webkit repo in the same directory as the rest of the bug-finder?

I'm not sure, to be honest, but probably unlikely.
It requires Python 2.7.

 

[IbbyPlays]

I'm not sure, to be honest, but probably unlikely.
It requires Python 2.7.

Gr8. Any tips on installing beatifulsoup4? I've been trying to but it keeps on ending with:

error: could not create '/Library/Python/2.7/site-packages/bs4': Permission denied

 

[Marionumber1]

Is this crash exploitable, considering it crashes before loading the webpage (so it might not load out code) and the current exploit doesn't?

We've evaluated it, and it probably isn't.

 

[endoverend]

I wouldn't focus on one crash guys. There are tons of layout tests in the program, just try them yourself and I'm sure you'll find something. It's a community effort. If dojafoja would be so kind as to add me to the access list for this thread I would be happy to include a list of found crashes in the OP.

 

[dojafoja]

I wouldn't focus on one crash guys. There are tons of layout tests in the program, just try them yourself and I'm sure you'll find something. It's a community effort. If dojafoja would be so kind as to add me to the access list for this thread I would be happy to include a list of found crashes in the OP.

I honestly wouldn't mind at all.... I'm just wondering though how the community feels about having a public list of crash-grade bugs we find. On one hand we would be giving Nintendo a nice consolidated list of bugs to patch. On the other hand, it's not like they don't have the resources to know about ALL bugs that will crash their browser. Maybe I could take a poll? I honestly don't care either way, I really don't plan on utilizing the kernel exploit anyways unless I see a xbmc port I might reconsider lol. In the meantime I've decided to say screw it because my kids use the console every single day for Netflix,Hulu,Youtube an online gaming. All of which require the latest firmware and I'm not willing to give that up. I just wanted to contribute what I could to help all the people that wanted to help and be involved but didn't know how or where to begin. I do this shit for fun because I learn a lot in the process. Like this go around, I learned a bit of multi-threading, plus I had never written any kind of text parser so I wanted to give it a shot. :-P

 

[Marionumber1]

For whatever reason, Nintendo does not want to update WebKit as a whole. They're left to fix bugs individually, so they need to find them. We shouldn't make it easier for Nintendo to find them. At least make them do the work, and don't just hand it to them on a silver platter.

 

[endoverend]

For whatever reason, Nintendo does not want to update WebKit as a whole. They're left to fix bugs individually, so they need to find them. We shouldn't make it easier for Nintendo to find them. At least make them do the work, and don't just hand it to them on a silver platter.

I guess if that's the way you want to go, then so be it. But I know I'll be staying at the latest version of the console, for the same reasons dojafoja described. I guess findings are better off staying in a private message to you or another developer. But the reason I wanted to make a list of bugs was because most of them are definitely not exploitable and I think anyone who would find something useful would have enough sense to not publicize it.

 

[dojafoja]

For whatever reason, Nintendo does not want to update WebKit as a whole. They're left to fix bugs individually, so they need to find them. We shouldn't make it easier for Nintendo to find them. At least make them do the work, and don't just hand it to them on a silver platter.

This answers the question guys. No public list. The community needs to somehow create a private pool of bugs to give to developers who can find which ones are exploitable. I'm thinking the devs probably don't want to be spammed every time a bug is found that crashes the browser either so probably create a private pool and then pass on the information.