Re: Adobe Alternatives

[Jeffrey Walton <noloader () gmail com>]

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