7

Tools that deal with SWFs, PDFs, OTF... seem to suffer from a disproportionate amount of vulnerabilities. Is the a characteristic in the formats that Adobe creates that makes them more susceptible to be broken?

Related:

Why are Adobe Flash exploits found so often? Note: I'm not asking why, rather what is common to all of these Adobe technologies.

What was behind the surge of Adobe Flash Player vulnerabilities/patches in 2015?

Jedi
  • 3,906
  • 2
  • 24
  • 42
  • I think it's a matter of more resources used to find a vulnerability, as Adobe is a very known suite of products. Just like why there are more malware in Windows than in MacOs or Linux? Because the user base is much bigger, and therefore, people spend more time creating malware for Windows instead that for the other OSes. – The Illusive Man Apr 01 '17 at 15:04
  • I suspect it has to do a lot more with their prevelance and – ste-fu Apr 01 '17 at 15:06
  • The prevalence argument was not accurate even for Windows v/s Linux. [This article](http://www.revpol.com/files/www-theregister-co-uk-2004-10-22-security_report_windows_vs_linux-print.html_.pdf) starts by discussing how prevalence is a factor, but not the only determinant. System design and architecture also play a role, as do the processes used while building the format/spec. – Jedi Apr 01 '17 at 15:10
  • 4
    *"Tools that deal with SWFs, PDFs, OTF... seem to suffer from a disproportionate amount of vulnerabilities."* - can you provide proof for this claim? And given that the majority of the tools processing with vulnerabilities in SWF and PDF come from a single vendor: couldn't it be that the vendor has a software quality problem instead? And as for OTF and other font formats I think the problem is that the code was originally never intended to deal with deliberately invalid fonts and was only optimized for speed. Same is true for image formats. – Steffen Ullrich Apr 01 '17 at 16:41
  • @SteffenUllrich. It is a subjective interpretation, solely based on the sheer number of patches that Adobe needs to put out compared to their competitors. And other software that deals with Adobe-guided standards (Foxit, for example) also seem to have a lot of vulnerabilities. Adobe does have a reputation for extremely insecure products (e.g. [7 of the "top 20" most vulnerable software from 2016](https://www.lifehacker.com.au/2017/01/which-software-had-the-most-vulnerabilities-in-2016/), but is this a format design problem or a software engineering problem? – Jedi Apr 01 '17 at 17:26
  • @SteffenUllrich, the second half of your comment is actually what I thought the reasons were. Adobe seems to be more likely to build formats that only work well as long as the files are not malformed (the focus is only on the steel thread). – Jedi Apr 01 '17 at 17:27
  • 2
    @Jedi: I don't think so. Problems with processing malformed data are all over the place, notably with image formats, codecs or fonts (not only ODT). And this is usually because the tools and libraries where simply written with only well-formed data in mind. This kind of thinking is very common and not specific to file formats: just think of all the XSS, SQL injections etc. – Steffen Ullrich Apr 01 '17 at 17:36

2 Answers2

5

There are many factors but these are some:

  1. They're non-standard binary files. Not based on XML/JSON/YML/etc, which means that each Adobe product developer has to reinvent their own parsers, which is one of the most difficult and tedious tasks for programmers.

  2. These files are often designed with efficient processing, with little thoughts given to ease of writing secure implementation. For example, PDF contains an xref table, which contains the byte offset that programs have to seek() to find sections. If that's not bad enough, this xref table is located at the end of the file, necessitating PDF parser to read the file backwards from the end of the file. To add even more to complication, there can be more than one such xref tables in a single file, and some entries can be inactive or overridden by later entries.

  3. The binary format can contain conflicting information. For example, a PDF section can be specified in different ways: each section contains the length of the section in ASCII numbers, an "endobj" marker, and entries according to the xref table. These conflicting informations means that different parts of Adobe's product and different implementations may rely on different ways to interpret the same section.

  4. These file formats can contain Turing-complete executable code. A PDF file can contain Javascript code, a SWF file can contain ActionScript. Like any other document macro language (e.g. VBScript in MS Office files, JavaScript in HTML), these Turing-complete languages are a source of bugs of their own.

  5. PDF touts itself as a format that should look the same everywhere, and you can open ancient PDF and expect it to render the same in modern readers. Some ancient PDF generators produced faulty PDF, which happens to rely on a bug in the old Reader/Acrobat. Rather than fixing the program and rejecting these faulty files as corrupted, Adobe programmed these hacks to keep these faulty files readable. Unfortunately, these hacks aren't documented, so it makes it difficult for other implementations to keep up with Adobe on how exactly to parse these malformed documents.

  6. The formats have massive amount of features that's tangential to document formatting. Rather than using separate layers, Adobe like to implement everything in their own format specification. For example, many document formats like ODF, DOCX, JAR are simple XML/Class or and other metadata in a regular zip file. PDF intermixes compressed format into regular data stream, you can't just use a regular zlib decompressor to get uncompressed PDF. Same thing with digital signatures and version control.

Adobe is still making a lot of money despite these problems, which is probably the biggest reason why they don't really feel the need to care to change their developer culture.

Jedi
  • 3,906
  • 2
  • 24
  • 42
Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • Thanks, this was a really informative answer. Would you also assert that Adobe's formats are more prone to vulnerabilities, or is this par for the course? – Jedi Apr 03 '17 at 02:50
4

Because Shockwave/Flash used a intermediate bytecode that gets generated from ActionScript, it is the code generator and the library found in the flash_player plugin that has extremely poor security coding practice.

Also, flash_player plugin (along with Firefox JS engine, Chrome JS engine, and node) makes use of dynamic executable code generation when reading these intermediate bytecodes that will continue to makes it vulnerable for the near forseeable future.

I learned all of this while using IDA Pro on it.

And it still has plenty of "opportunities".

John Greene
  • 390
  • 2
  • 6
  • This guy nailed the fact that ActionScript compiler was wobbly...way back in 2010. http://web.archive.org/web/20131126092058/http://www.fortiguard.com/files/CanSecWest2011_Flash_ActionScript.pdf – John Greene Apr 13 '17 at 18:48