Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Just because an exploit is a silly doodle, that doesn't mean we can just ignore the exploit vector.
Or perhaps Softbound.
Posted Sep 1, 2012 18:21 UTC (Sat) by cmccabe (guest, #60281)
If we did something similar for PDF readers, all a bug in the PDF rendering code could do is change the way the PDF looks-- which is not an exploit.
Posted Sep 3, 2012 10:36 UTC (Mon) by ekj (subscriber, #1524)
HTML-injection-attacks can become interesting if a bug in the rendering means that you can affect the looks of a part of the page which you're not supposed to be able to affect.
Let's say you're allowed to enter plain-text but that <strong>-tags are allowed and preserved. If a bug in the rendering means that the user is able to affect not only how his comment is rendered, but also some other arbitrary part of the page, then that is a potential security-problem.
The assumption that the entire html-string being rendered is from *one* source, and thus that it's always a noninteresting bug that one part of that string can affect other parts of that string, isn't valid. It's *incredibly* common for websites today to output HTML where parts of the HTML are strings entered by users. (sanitized to varying degrees)
Posted Sep 5, 2012 3:10 UTC (Wed) by cmccabe (guest, #60281)
However, taking this to its logical conclusion leads to a kind of reductio ad absurdum: any bad behavior could be exploited by someone, therefore all bad behaviors are security bugs. Therefore the only way to get secure software is to run only bug-free software-- i.e., no software.
In the real world, we accept that deleting your files and p0wning your home directory is a heck of a lot more interesting than changing the bold tag on something outside your IFRAME. The former could be used for industrial espionage. The latter will just lead to someone navigating away from your site, because it "looks weird."
Posted Sep 5, 2012 8:36 UTC (Wed) by ekj (subscriber, #1524)
HTML-rendering-engines live in a world where a common use for them, is to render a string of HTML where different parts of the string comes from different entities which you trust to differing degrees. LWN itself is an example of this, the text you're reading right now is a string entered by me, while the layout and rest of the window is markup and text made by LWN.
This is the reality of the situation. The same isn't true for (say) an image-viewer. It's not, infact, common to be viewing a jpg-image where the pixels in a certain part of the picture are created by one entity, and the pixels elsewhere by another entity. If it was, then yes, the situation would be parallell.
Often it doesn't matter. But sometimes it matters very much indeed. If I pay a bill by net-bank, I can enter a string that is displayed (in the net-bank) to the person receiving the payment. If it was possible for me to enter a string that would, for example, change what the recipient sees in the "amount" field, not merely the "comment"-field, that'd be a major problem.
Yes, they sanitize the strings (allow only [a-zA-Z 0-9]). This reduces the attack-surface, and makes sense. But the basic principle of the attack remains: bugs in the rendering-engine may make one part of the string able to affect other parts which it shouldn't by the standard, such bugs are security-bugs.
Yes that means many bugs in rendering untrusted content are security-bugs. A bug in OpenOffice that somehow causes what is displayed on screen (for a specially crafted document) to differ from what is printed, is a security-bug. (imagine what would happen if someone read a contract on-screen, then printed and signed the paper-copy without validating that the paper-contract match the on-screen contract)
Posted Sep 6, 2012 0:24 UTC (Thu) by cmccabe (guest, #60281)
As far as HTML goes, sandboxing the HTML rendering thread is an important step towards shutting down browser-based attacks. At the end of the day, perfect security is impossible-- yes, even in Java. However, additional layers of security can add to your confidence level. BTW, if you haven't read "reflections on trusting trust," you should check that out.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds