Security Basics mailing list archives
Re: Adobe Alternatives
From: Jeffrey Walton <noloader () gmail com>
Date: Thu, 15 Oct 2009 11:03:20 -0400
Hi Jason,
I do agree with Stephen - just because you don't hear about issues does not mean its an acceptable solution.
I agree with you, Stephen, and Ron. However, don't assume I buy into 'Security through Obscurity'. I don't. My reasoning is outlined below.
Go back to your model and determine what you are trying to solve
As an admin, my model is simple - I want secure and robust software on the network. It's simply performance based: focus on outcomes [1]. The more interesting question is, "What is Adobe's model?".
and what risk you are willing to accept.
I'm not sure what is broken over at Adobe, but the outcome appears to be chronic failures due to lack of parameter validation. So this one is easy - I am not willing to accept risks associated with using Adobe's software. And I'm still confounded by the fact that Adobe accepted, and then redistributed, a debug build of a DLL from a vendor [2]. When I raised the issue with the company, I was asked for a proof of concept. It has been my experience that companies which ship debug builds do so for one of two reasons: 1) the module has initialization problems*, or 2) the module has timing problems. The fact that the DLL was accepted is a testament to low quality standards. It points to yet another broken processes at the company. With the respect to using alternatives, one of the following will apply: 1) the alternative will be less secure than Adobe's offering 2) the alternative will be about as secure as Adobe's offering 3) the alternative will be more secure than Adobe's offering Given that Adobe has a track record of chronic parameter validation failures (and other reasons offered in this thread), I believe that an alternative *will not* be less secure. So I don't expect (1) to apply. (Adobe fans: your rebuttal should attack this claim). If an alternative accepts third party software without acceptance testing (or knowingly accepts deficient software) or does not consistently validate parameters, then my situation has not improved. In this case, (2) applies. For the record, my Foxit Reader installations *do not* include third party modules so: "at least one one alternative does not suffer from distributing flawed third party modules". If an alternative follows secure coding practices as outlined in [3,4,5,6] (et al), then I would expect (3) to apply. I would also expect the alternative to suffer an occasional issue, but I would not expect a chronic pattern to emerge. In this case, I would claim that the alternative is more secure than Adobe's offering. Jeff * initialization problems as in the use of uninitialized variables, and not DllMain initialization. [1] http://www.govinfosecurity.com/articles.php?art_id=1832 [2] Onxi32.dll by Lextek, http://www.lextek.com/ [3] Writing Secure Code, ISBN 0-7356-1722-8 [4] Writing Secure Code for Vista, ISBN 0-7356-2393-7 [5] Software Security: Building Security In, ISBN 0-3213-5670-5 [6] 19 Deadly Sins of Software Security: Programming Flaws and How to Fix Them, ISBN 0-0722-6085-8 On Wed, Oct 14, 2009 at 12:25 PM, Jason Troy <jason.troy () gmail com> wrote:
I do agree with Stephen - just because you don't hear about issues does not mean its an acceptable solution. Go back to your model and determine what you are trying to solve and what risk you are willing to accept. I love how the thread got quiet right before they announced this: APSB09-15 - Security Updates available for Adobe Reader and Acrobat "... vulnerabilities could cause the application to crash and could potentially allow an attacker to take control of the affected system. This update represents the second quarterly security update for Adobe Reader and Acrobat." http://www.adobe.com/support/security/bulletins/apsb09-15.html Vulnerability identifier: APSB09-15 CVE number: CVE-2007-0048, CVE-2007-0045, CVE-2009-2564, CVE-2009-2979, CVE-2009-2980, CVE-2009-2981, CVE-2009-2982, CVE-2009-2983, CVE-2009-2984, CVE-2009-2985, CVE-2009-2986, CVE-2009-2987, CVE-2009-2988, CVE-2009-2989, CVE-2009-2990, CVE-2009-2991, CVE-2009-2992, CVE-2009-2993, CVE-2009-2994, CVE-2009-2995, CVE-2009-2996, CVE-2009-2997, CVE-2009-2998, CVE-2009-3431, CVE-2009-3458, CVE-2009-3459, CVE-2009-3460, CVE-2009-3461, CVE-2009-3462 -- JT On Sun, Oct 11, 2009 at 09:30, Stephen Mullins wrote:How much trouble would it be to bundle a Foxit exploit in a .pdf file containing an Acrobat/Reader exploit? Adobe easily maintains over 95% of the .pdf reader market, so obviously it would be both a waste of time and resources to develop exploits for alternative readers and then actively try to utilize them. On the other hand, if the bad guys aren't paying much attention, neither is anybody else. That means an alternative .pdf file viewer could have an active exploit floating around for a very long time before it was detected (IF it is detected, virtually all professional organizations use Adobe and a home user would experience the secondary payload and not know how it got there so nothing would be reported). I don't have a lot of faith that some obscure freeware program is necessarily more secure. It might make you feel more secure because you don't hear about exploits being released every other week like you do with Acrobat, but in reality you may be worse off. You're hoping that nobody bothers to develop exploits for the alternative program, and hoping that even if they do, you won't run into their payload delivery method because most of the malicious .pdf documents are targeting Adobe. So which is better? Fully patched Adobe Acrobat/Reader with dozens (hundreds? thousands?) of "researchers" of every stripe pounding away at it day and night to discover vulnerabilities, or an obscure third party program that *almost* nobody bothers to look at? In the one case you're secure until the next Adobe exploit, and in the other case you're just playing percentages and hoping for the best. Just throwing some thoughts on the matter out there. Steve Mullins[SNIP]
------------------------------------------------------------------------ Securing Apache Web Server with thawte Digital Certificate In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates. http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1 ------------------------------------------------------------------------
Current thread:
- Re: Adobe Alternatives Stephen Mullins (Oct 13)
- Re: Adobe Alternatives Jason Troy (Oct 14)
- Re: Adobe Alternatives Jeffrey Walton (Oct 15)
- Re: Adobe Alternatives Jason Troy (Oct 14)