Need Cultural Change at Adobe – Vulnerabilities Too Numerous

From their long and growing list of products and services, Adobe appears to be attempting to dominate the rich, user-centric application, communications, and information-delivery environments.
(see: http://www.adobe.com/products/ and http://labs.adobe.com/)

They have been pumping out new functionality, new development environments, new languages, etc. at a pace that is difficult to imagine.  How do they manage the pool of energy and creativity required to initiate and maintain their current (accellerating) trajectory?

In financial services, “cool” and “new” are not unknown, but we need to manage them into business environments that must constantly demonstrate a threshold level of due care and due diligence.

Adobe products, new and old, keep getting hacked.  On the consumer/customer as well as corporate fronts, the latest include critical vulnerabilities in Flash/AIR/Flex and Adobe Reader/Acrobat.  Both involve remote exploit and potential for executing arbitrary code on an end-user’s PC.  Because Flash and PDF files are found “everywhere” throughout the Internet, this set of vulnerabilities presents a particilarly difficult risk equation for PC users — and for the information security personnel who serve them.

There have been at least 8 publically-disclosed vulnerabilities in Adobe Flash, and at least 6 in Adobe Reader/Acrobat in the last year.  That extended a well-established tradition of vulnerabilities another year.

Because these Adobe products are found on virtually all Windows PCs, the culture at Adobe that generates and accepts this tradition of regularly-vulnerable software must be modified.  We need to raise the volume of our input to Adobe on this topic, and consider going broader with this campaign, maybe even to investors.

What do you think?  What would work most effectively?

— References —
Many of the Adobe collection can be found at: http://www.adobe.com/products/ and http://labs.adobe.com/

Adobe Flash Player (Flex/Air as well) Multiple Vulnerabilities  (Feb 25, 2009 http://secunia.com/advisories/34012/ and http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=773)
Adobe Reader/Acrobat JBIG2 Stream Array Indexing Vulnerability (Feb 2, 2009 http://www.kb.cert.org/vuls/id/905281 and http://secunia.com/advisories/33901/)

SSL/TLS – Maybe Not So Safe

Moxie Marlinspike presented “New Tricks For Defeating SSL In Practice” at BlackHat DC 2009 this week.  I listened to the presentation this evening.  It is an excellent overview of SSL/TLS implementation vulnerabilities by an individual who is in command of this territory.  If you are in a business that depends upon SSL/TLS for a significant portion of your information risk management, I recommend you listen to this presentation too.

I believe most of us need to think through how much we can depend upon SSL/TLS to mitigate the risks associated with attacks on our sensitive information in transit.  Marlinspike reviewed the history of SSL/TLS implementation weaknesses and attacker’s clever ideas and technology that leave us currently in a situation where many of our best “secure” web sites are  openly vulnerable to man-in-the-middle attacks.  All our “locks” and vendor certifications may be rendered impotent to the types of attacks described by Mr. Marlinspike.

Most financial services corporations maintain “secure” Internet-facing customer, marketer, and partner portals.  A material portion of our security proposition depends on SSL/TLS for maintaining the confidentiality and integrity of the sensitive information that flows between our servers and our client’s browsers.  That equation requires all parties to respect the assumption that there will be onlyone server-browser pair for each session, and any intermediary proxy devices are acting only as purely passive relays.  This presentation will put those assumptions to the test.  I strongly recommend working through this session, and then doing so again with your information security peers, your application security specialists, and maybe even your management.

After you do, I would like to know what you think and what you might be doing differently in the future?

— References —

A recording of “New Tricks for Defeating SSL in Practice” is available at: http://securitytube.net/Defeating-SSL-using-SSLStrip-(Marlinspike-Blackhat)-video.aspx and the slides are available at: http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf

BlackHat: http://www.blackhat.com/

Contact Moxie Marlinspike at:moxie at thoughtcrime.org

Browser As Your Company’s Outer-Most Application Edge

Rich Internet Applications deliver increasing functionality, and with it, increasing amounts of sensitive information, out to end-user’s browsers.  Too often this is a browser and client-platform wasteland without control or consistency. How can we protect our information assets and brand?

More and more regulated personal or health-related information, more valuable intellectual property, more corporate secrets, are reaching our browsers.  As more of our application infrastructure is extended into end-user browsers, demonstrating a threshold level of due diligence is getting more complicated.

Remember when the threshold seemed to be the presence of a top-tier firewall at your Internet perimeter?  Or when a DMZ was enough?  Then hardened web servers, SSL encryption, infrastructure to provide increasingly sophisticated authentication schemes and session management, and more…  The latest battle-ground has been the applications themselves.

Browse the resources at OWASP.org or google ‘web “application security” vulnerabilities 2008‘.  Application-layer vulnerabilities are consuming a greater percentage of the active Internet attack surface.  Microsoft recently reported that 90% of vulnerabilities discovered by researchers were in applications.  They also report that nearly 50% of all vulnerabilities are now rated HIGH severity or higher.

As we extend more of our application functionality, and more of our sensitive and valuable information out of the enterprise into end-user browsers, how are we dealing with the risks associated with that environment?  The “Browser Security Handbook,” written and maintained by googler Michal Zalewski, is an extensive and exhaustive resources for your application architects, designers, coders, quality assurance personnel, along with your application security engineers and assessment staff [more than 75 pages of lucid, often spartan text].  When control matters, the many differences along the many facets of browser technology need to be effectively dealt with. There is no magic to save us.  This is, and is going to continue to be really hard work.  The additional challenge will be to find ways to wring competitive advantage and profits out of these investments in application security.

I believe that this handbook stands alone.  Contrary to what most of us would assume, much of this resource is simply excellent writing.  No waste, some beautiful sentences and paragraphs — even when writing about “Document Object Model” or “Browser-side Javascript.”  Michal Zalewski’s work is a joy to read.  Because this resource now exists, we all have one less excuse to avoid the inevitable slog through application security enhancements and upgrades, quality/vulnerability testing, and financing the whole endeavour.

— References —

Open Web Application Security Project. http://www.owasp.org

Microsoft Security Intelligence Report volume 5 ( January – June 2008 ) http://www.microsoft.com/downloads/details.aspx?FamilyId=B2984562-47A2-48FF-890C-EDBEB8A0764C&displaylang=en

“Browser Security Handbook.” http://code.google.com/p/browsersec/wiki/Main