wkhtmltoimage for TIFF

[Yozons eSignForms]

Is there any plan on building wkhtmltoimage that supports TIFF images again?

[Ashish Kulkarni]

Considering that there are always vulnerabilities in libtiff and that
upstream development has stopped, I don't include TIFF support in the
default build. You can always enable it by setting this up before
running the build script:

export WKHTMLTOX_QT_CONFIG=remove:-no-libtiff -system-libtiff

[Yozons eSignForms]

Thanks for your reply.  I was hoping to avoid builds since (as you know full well doing this work yourself! thank you for that!) custom builds are complicated for the various runtime platforms (like we develop in Java on Windows, but otherwise never build any Windows apps and we tend to deploy on various Linux builds that we also never develop on).

What is the security concern for running wkhtmltoimage on my computer using HTML I give it to generate a TIFF?  The software is not run by others nor is it network connected for outside attacks.

I have read about some issues with TIFF, but these do not seem to come into play for the wkhtmltoimage usage scenario.  I mean, QT likely isn't trying to craft broken input to break libtiff based on the HTML we supplied to wkhtmltoimage.

I mean, PDF files have a long history of malicious exploits, too, but these are based on crafting bad PDFs, not on generating a PDF.  Most of the TIFF exploits appear to be in gif2tiff or with malicious TIFF input.  But I agree that it seems to have a long list associated with it, though I didn't see any related to TIFF creation by software not trying to exploit it (which I presume QT and wkhtmltoimage don't attempt).

So, if TFF generation can make a comeback, I'd much appreciate it.

[Ashish Kulkarni]

The problem is that when you enable TIFF support, it is enabled for
both reading and writing files [1]. So for your use case (writing TIFF
files) it may not be having any security impact, but it automatically
enables support for reading TIFF files -- which is very dangerous,
considering that wkhtmltopdf can be used to convert any random URL on
the web, which can have a reference to a malicious TIFF file.

I'm open to enabling TIFF support on Linux (where distributions do
issue security updates) but not for Windows (where you have to compile
your own libtiff). I'm not sure whether OS X has libtiff built-in but
I highly doubt it (as even libpng is not built in) -- so the same
reasoning that goes for Windows applies here.

[1] http://qt-project.org/doc/qt-4.8/qimage.html#reading-and-writing-image-files

[Yozons eSignForms]

On Friday, October 17, 2014 11:05:03 PM UTC-7, Ashish Kulkarni wrote:

The problem is that when you enable TIFF support, it is enabled for
both reading and writing files [1]. So for your use case (writing TIFF
files) it may not be having any security impact, but it automatically
enables support for reading TIFF files -- which is very dangerous,
considering that wkhtmltopdf can be used to convert any random URL on
the web, which can have a reference to a malicious TIFF file.

I see.  Well, I appreciate the concern, but this seems more like something that should at most be disclosed as a disclaimer when using wkhtmltopdf with TIFF rather than a block on its use. For us, the HTML being converted is under our control and so there is no concern for malicious HTML.  After all, there have been bugs in PDF readers, Word, Linux (openssl, bash recently), spam/virus emails, web browsers, and of course Windows itself, all of which are attack vectors.  The same is true for all web forms and HTML editors -- users "can" create malicious content, link to malicious content, XSS, phishing, but it's up to the programmers to "clean" the input when allowing outside data to be used, so it's really no different than anything else.

I'd be open to requiring a runtime option/flag to enable TIFF output if that would help, but perhaps that's not easily done to tell QT to use or not use it.
 

I'm open to enabling TIFF support on Linux (where distributions do
issue security updates) but not for Windows (where you have to compile
your own libtiff). I'm not sure whether OS X has libtiff built-in but
I highly doubt it (as even libpng is not built in) -- so the same
reasoning that goes for Windows applies here.

Well, this would work for us since our particular need now is for TIFF on Linux only.  That would be much appreciated!
 

[1] http://qt-project.org/doc/qt-4.8/qimage.html#reading-and-writing-image-files

I don't suppose QT has a way to tell it to only allow writing TIFFs and not reading them.  We just want to create TIFFs.

[Ashish Kulkarni]

>> The problem is that when you enable TIFF support, it is enabled for
>> both reading and writing files [1]. So for your use case (writing TIFF
>> files) it may not be having any security impact, but it automatically
>> enables support for reading TIFF files -- which is very dangerous,
>> considering that wkhtmltopdf can be used to convert any random URL on
>> the web, which can have a reference to a malicious TIFF file.
>
>
> I see. Well, I appreciate the concern, but this seems more like something
> that should at most be disclosed as a disclaimer when using wkhtmltopdf with
> TIFF rather than a block on its use. For us, the HTML being converted is
> under our control and so there is no concern for malicious HTML. After all,
> there have been bugs in PDF readers, Word, Linux (openssl, bash recently),
> spam/virus emails, web browsers, and of course Windows itself, all of which
> are attack vectors. The same is true for all web forms and HTML editors --
> users "can" create malicious content, link to malicious content, XSS,
> phishing, but it's up to the programmers to "clean" the input when allowing
> outside data to be used, so it's really no different than anything else.

That's a very wrong argument -- why should you enable features which
are known to have security vulnerabilities? By that logic, I should
not have released 0.12.1.1 and 0.12.1.2 for Windows -- a disclaimer to
the effect that accessing sites via SSL would be possibly dangerous
would have sufficed. You cannot restrict the uses to which a tool can
be put to use for the convenience of the developers -- it goes against
the very spirit of free software.

> I'd be open to requiring a runtime option/flag to enable TIFF output if that
> would help, but perhaps that's not easily done to tell QT to use or not use
> it.

Nope, not possible.

>> I'm open to enabling TIFF support on Linux (where distributions do
>> issue security updates) but not for Windows (where you have to compile
>> your own libtiff). I'm not sure whether OS X has libtiff built-in but
>> I highly doubt it (as even libpng is not built in) -- so the same
>> reasoning that goes for Windows applies here.
>
> Well, this would work for us since our particular need now is for TIFF on
> Linux only. That would be much appreciated!

I'll see if that can be done for a future 0.12.2 build.

> I don't suppose QT has a way to tell it to only allow writing TIFFs and not
> reading them. We just want to create TIFFs.

Nope, not for the built in image formats.

[Yozons eSignForms]

Ashish,

Thanks for looking to add TIFF to Linux builds.  That would solve my requirement so I can upgrade from 0.11.

But I think you misunderstand me (or we just disagree <smile>). Just because there's a security hole in a little used feature that can happen, doesn't mean the entire feature must be removed.  All features are used with some sort of tradeoff (we use Windows/javascript/C/SSL/bash/credit cards/glass windows/etc despite their known vulnerabilities). 

A TIFF input vulnerability may be real for some use cases, but it has there is ZERO vulnerability for our use case.  We generate the HTML that is subsequently converted to PDF and thus there are no references to corrupting TIFF inputs (most HTML rendering systems won't even show a TIFF, but they may still load them).  Besides, if there is corrupting HTML with TIFFs, it is far more likely that the exploit will affect users viewing the HTML in their browsers than a server component that generates PDFs for its customers using HTML they have.

Can the QT method http://qt-project.org/doc/qt-4.8/qimagereader.html#setFormat be used to change the supported formats?  A call to http://qt-project.org/doc/qt-4.8/qimagereader.html#supportedImageFormats could determine if TIFF is present and remove it for the image reader when it is by calling setFormat with all but TIFF.

Anyway, I really appreciate your help to resolve our requirement to generate TIFFs for our users who still work with them.