| |||||||||||||
So which/how many users use Adobe Reader on Linux ?So which/how many users use Adobe Reader on Linux ?Posted Aug 17, 2012 20:51 UTC (Fri) by khim (subscriber, #9252)In reply to: So which/how many users use Adobe Reader on Linux ? by Lennie Parent article: Google warns of using Adobe Reader - particularly on Linux (The H)
So how many users of Adobe Reader on Linux could there be ? Good point. If you'll recall that security-wise evince is worse then Adobe Reader and there are more users of evince in general... it's not clear what the hoopla is all about.
(Log in to post comments)
Valgrind? Posted Aug 19, 2012 7:29 UTC (Sun) by gmatht (guest, #58961) [Link]
Would running Acrobat or Evince under valgrind with the right options make it safe? It would be cool if there was a way to run existing software in a mode that gave it well defined and hard to exploit behavior to moving a pointer outside its original malloc'd space. I've heard the x32 abi may make it easier to implement Fat pointers, though that doesn't help much for Evince.
Or perhaps Softbound. Posted Aug 19, 2012 13:16 UTC (Sun) by gmatht (guest, #58961) [Link] Opps, I meant it wouldn't help for Acrobat (because we can't recompile it). Anyway for code that we can recompile with LLVM I guess the answer is something like SoftBound, assuming the code doesn't rely on undefined behavior just to work at all. Apparently the overhead of softbound can be under 20%, so it seems like it could make a good default for development versions of all C programs. I am not sure if SoftBound supports C++ yet though.
Or perhaps Softbound. Posted Aug 19, 2012 21:23 UTC (Sun) by cmccabe (guest, #60281) [Link]
We already have a way to do this. See http://lwn.net/Articles/353203/, where Dan Walsh explains how to sandbox Acroread using selinux. No speed hits required, and it catches more things than just boundary errors.
I still think that a seccomp-based solution would be the way to go. Similar to what Google did with Webkit in Chrome. That would not require SELinux to be enabled (it's not available on my current distribution) and would be a true upstream solution.
Or perhaps Softbound. Posted Aug 27, 2012 21:07 UTC (Mon) by idupree (subscriber, #71169) [Link]
As I understand it, neither the SELinux nor seccomp methods catch the boundary errors. The boundary errors can still be used for exploits that display silly doodles in the Acroread window instead of displaying the PDF, for example. Catching the boundary errors as boundary errors means we can prevent attacker-controlled code execution altogether in some cases.
Or perhaps Softbound. Posted Sep 1, 2012 3:49 UTC (Sat) by cmccabe (guest, #60281) [Link]
> As I understand it, neither the SELinux nor seccomp methods catch the
> boundary errors. The boundary errors can still be used for exploits that > display silly doodles in the Acroread window instead of displaying the > PDF, for example.
Um, displaying content is not an exploit. Or if it is, the only secure PDF decoder is /dev/null.
I don't need to be a hacker to give you a PDF that displays a silly doodle. I can just create a pdf that embeds a silly doodle.
Or perhaps Softbound. Posted Sep 1, 2012 15:06 UTC (Sat) by bronson (subscriber, #4806) [Link]
As you quoted, the OP is talking about creating a PDF that displays a silly doodle due to a boundary error.
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) [Link]
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.
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.
|
|||||||||||||