Security and Our Products

 

Overview

Security considerations are baked into all aspects of our software lifecycle.

As part of this we are currently undergoing accreditation for ISO 27001.

Our software is:

• tested repeatedly and relentlessly. Over a period of over two decades we have amassed vast test suites which push the boundaries of our software to their limits to ensure they perform as expected. For products like ABCpdf this type of QA is performed by our build servers as soon as any changes are made. If something breaks or a regression error occurs we know about it immediately.
• penetration tested. We use third-party professional pen testers for independent validation of the security of our major products. Our white hat experts attempt to find ways to compromise the software so that we can all be confident that hackers will not.
• digitally signed. This means that you can be confident that the software you get from us is the same software which we released for you. As different parts of the software are loaded we perform our own signature and validity checks to ensure that files have not been tampered with after installation.
• obfuscated. This makes it exceptionally difficult to reverse engineer, to understand how it might be manipulated and what attack surfaces might exist.
• modular. This means you only call into and use the parts you need. Reduce the size of the software and you produce a reduced attack surface. Feel welcome to throw out that HTML engine or JavaScript module if you are not using it.
• designed to be run in a limited permission environment. By doing this, you sandbox it away from your other systems. You can harden the environment as much as you like to ensure that it is completely isolated from anything else.
• based on defense in depth. In addition to external checks performed by Windows we perform our own checks and isolation. For example the ABCChrome and WebKit HTML rendering engines operate inside sandboxes which limit access using our cutting edge FireShield technology.

 

Core Code

The kernels of products like ABCpdf - the most critical parts - are closed source. This offers a number of advantages over open source solutions, notably in the area of security.

Open source solutions are vulnerable to exploitation precisely because they are so visible. Large numbers of people actively look through the code to try and find exploits which can be applied to any dependent product.

The industry of open source exploit-mining results in the production of a variety of reports. Some are distributed in open source databases and can require that you update immediately to avoid a well publicized crack being used against you. Others are held in private collections so that nefarious actors can take advantage of them.

Closed source has an advantage here because the only way to look through the code is by reading the raw assembly instructions or the obfuscated code. This is extremely challenging and makes finding exploits many orders of magnitude harder. There are easier alternatives. The result is that few if any exploits are located.

Even if an exploit is found, this type of closed source code has advantages. With open source there is no record of people using a particular product. If a vulnerability is found the only option is to make it public so that everyone knows they need to upgrade. The problem here is that this knowledge becomes public both for those that need to avoid the exploit and also those who may wish to take advantage of it. With closed source licensed code, one can inform all clients without advertising anything to the wider world.

Our Open Source

Our open source extensions are generally quite simple. They are designed to demonstrate how to do things rather than provide complex code.

This simplicity means that you can understand them and modify them yourself. There is little room for vulnerabilities to creep in because they are so straightforward.

These things are not like engineering documents - more like recipes. While there might be a hidden flaw in a design for an aircraft it is much more difficult to hide a flaw in something so simple.

A recipe for tomato soup which contains apples instead of tomatoes is fairly obviously wrong.

Third Party Open Source Libraries

We use a variety of small open source libraries for particular areas of functionality.

The versions we use are tried and tested. They are neither so new that their provenance is uncertain, nor so old that they contain significant security flaws. There is a sweet spot when it comes to these things and that is the point we try to hit. Think little bear’s porridge.

Libraries are specific to particular modules. So you may find that a legacy HTML engine contains a legacy JPEG library. The solution here is not to update the library - it is to use a more up to date HTML engine.

The libraries themselves are well embedded, so inputs are generally vetted fairly carefully before presentation. This means that there is a limited attack surface exposed simply because it is difficult to get unvetted content through to the final insertion point.

 

The most major PDF exploits reported so far, were uncovered by a team from Ruhr University in February 2019.

https://www.pdf-insecurity.org/

This was reported on channels such as ZDNet,

"Researchers faked signatures on 21 of 22 desktop PDF viewer apps and 5 out of 7 online PDF digital signing services."

These flaws exist primarily in the area of digital signatures - an obviously sensitive realm. The team demonstrated how you could use simple structures to make a signed document appear valid when it was not, or different from the originally signed copy.

Since then, they have released a sequence of other ingenious exploits and found similar levels of vulnerability each time.

As the exploits have been reported we have tested the current version of ABCpdf against them.

ABCpdf has always passed without modification - it just does the right thing.

 

We do not make use of static security scans for a number of reasons. The main one is that we have the source code, so we know what elements are in place. However there are other more general reasons too.

The most major reason is related to lack of context. A static scan can only report what may be done - not what actually is done. This is a little abstract, but is a critical point.

Take a parallel example - your static scan reports someone with a knife. Yes this sounds alarming but is it? If they are on the street then yes perhaps, but if they are in a kitchen then probably not.

In terms of software, a call to a function that deletes a file is absolutely normal and will be contained in any non-trivial application. However such a call is potentially a massive problem if misused.

Similarly a call to read a file and calls to transfer data over the internet are again subject to massive misuse. Yet such calls are part and parcel of any non-trivial service.

That is the level of context which is missing. It can be large. One might even call it a flaw.

So you still want to perform static scans? If so…

Firstly, you must be aware of these major caveats regarding the results.

Secondly, you need to ensure you are scanning the right parts. Our software is modular so you should only scan the pieces you want to use.

For example, ABCpdf contains an HTML engine called WebKit which can be useful in very specific situations. WebKit is based on Qt 4 which ended support in 2015, WebKit itself was last updated in 2012. As such, if you scan it you will find that it contains legacy code. However if you are not using it then obviously it is not relevant.

The Manual Installation section of the documentation contains details about the different parts of ABCpdf, what they do, and from that you can work out which parts you should scan.

 

There are no known vulnerabilities in the ABCpdf source.

No client has ever reported that ABCpdf was used as part of an exploit.

No client has ever found a bug which could be used as a security exploit in any significant way.

So perhaps you are asking yourself, surely something must have gone wrong at some point?

In 2017 a professional penetration tester found a flaw in our PostScript code which could in theory be exploited. It would have taken a very specific set of code in place on the client side, combined with a lack of security, to produce a rather limited vulnerability. We fixed it immediately and notified all affected parties.

In 2004 Microsoft reported a buffer overflow vulnerability in GDI+ which could affect any applications which might use it. In some places and in specific situations our products might have been affected. This was resolved by a Microsoft update.

That is it. Over a period of more than twenty years and probably millions of installations - as used by almost half of the world's top 100 global brands.

Use our products in accordance with the documentation.

As long as you do that, they are bullet proof secure solutions.