Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

That's just for images. There could still be exploits in the HTML itself executing locally.


sort by: page size:

Without knowing more, that's a bit of an assumption. The vulnerability could be in image decoding, in which case an <img> tag is enough and no scripting is needed, but it could also very well require doing something funky with JavaScript.

Have you looked at how it's implemented? The image decoder is completely separate from the main browser and is in a sandboxed process (with restricted syscall and filesystem access). If the image decoder is exploited, there's nothing the attacker can do.

Not if the HTML hosting any of the JS is under attacker control.

>I think a similar exploit was used recently with .svg images - they can contain javascript (being XML) which will be executed by the browser. Not sure about the details however.

However, the JavaScript shouldn't execute if the image is embedded via <img>.


It's extremely unlikely. The chances of finding a RCE exploit that can be triggered without any Javascript are much lower.

It's not unheard of, of course. A bug in the CSS, HTML, or image parsing/rendering libraries can be exploited in this way.


As opposed to the denial of service style bugs like an empty src element in an img tag?

Yes, but the attacker can not get the browser to silently fetch the page (regardless of whether Javascript is disabled) just by sticking, say, an <img> tag somewhere.

You may be minimizing the attack surface, but just because a web browser only supports HTML and CSS doesn't mean it couldn't contain exploits.

It's possible that the HTML parser or image rendering library has a bug and that malformed HTML could cause a vulnerability in the browser. Granted, I believe it would be significantly easier to harden parsers and graphic rendering, but it's already been shown that certain image rendering libraries have been exploited[1].

[1] Example: http://technet.microsoft.com/en-us/security/bulletin/ms08-02...


No, the exploit is only for applications capable of interpreting JavaScript, such as web browsers.

I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?

since it's client side, it's physically impossible to completely prevent cheating :( using images instead of text and changing element id's and things would certainly make it harder to hack though!

There are exploits written in Javascript that run on a browser.

As far I remember JS exploit is possible. That's why Mozilla patched Firefox already.

Also: clean HTML enables hackability.

The clients don't need to be hacked, they simply run code as instructed by the server using standard, documented interfaces. Once the server is compromised, or any other party that can serve non-image content into the page origin, it's game over.

Indeed this is one of the most verbose and rambling exploit descriptions I've seen... apparently you can inject some script/HTML code into a field in your profile, but I don't see how that could lead to this:

but can also remotly execute arbitrary codes to access local web-server files or configs


Where? We've been told it is possible, but I have yet to see a JavaScript exploit that wasn't basically a canned demo.

It's also vulnerable to html injection... by design

It was a proof of concept; something like a thousand divs overflowing a buffer or something like that. I haven't seen anyone write an exploit for it.
next

Legal | privacy