User: Password:
Subscribe / Log in / New account

Or perhaps Softbound.

Or perhaps Softbound.

Posted Sep 1, 2012 18:21 UTC (Sat) by cmccabe (guest, #60281)
In reply to: Or perhaps Softbound. by bronson
Parent article: Google warns of using Adobe Reader - particularly on Linux (The H)

Think about the Chrome sandbox. The website rendering process is sandboxed using seccomp, so that even if it is compromised, it can't do anything but modify the way the web page it is displaying looks. Since you could do that anyway by editing the HTML for your web site, attacks against Chrome stop being interesting. (The exception seems to be attacks against Chrome's embedded Adobe Flash, which they are still in the process of fully sandboxing).

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.

(Log in to post comments)

Or perhaps Softbound.

Posted Sep 3, 2012 10:36 UTC (Mon) by ekj (guest, #1524) [Link]

That's not -entirely- true.

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)

Or perhaps Softbound.

Posted Sep 5, 2012 3:10 UTC (Wed) by cmccabe (guest, #60281) [Link]

Whenever software doesn't work correctly, it's a concern.

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."

Or perhaps Softbound.

Posted Sep 5, 2012 8:36 UTC (Wed) by ekj (guest, #1524) [Link]

I don't think it's quite that absurd.

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)

Or perhaps Softbound.

Posted Sep 6, 2012 0:24 UTC (Thu) by cmccabe (guest, #60281) [Link]

We're not talking about HTML, we're talking about PDF, where everything is supposed to come from one source (99.99999% of the time; Adobe introduced this Javascript embedding nonsense, but you shouldn't ever enable it).

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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds