2008.09.02 15:49 "Re: [Tiff] Some security fixes from RHEL", by Ron

On Tue, Sep 02, 2008 at 04:24:32AM -0400, Tom Lane wrote:

[ separate reply for a separate issue ]

As maintainer of Red Hat's libtiff package, I am now seriously wondering whether I must recommend that Red Hat disable TIFF support in any application that has any internet exposure.

There is not really any reason to single libtiff out. You can insert many application/library names here.

No, not really. Image processing libraries have a particularly bad name amongst the security community. I suppose that this isn't so much because their code was any worse than anyone else's, as that it's been an easy attack vector for both email and http hackers.

The relative complexity of the input data is a big killer. Sanitising a complex format that can define elements of its own structure and their interpretation is vastly more difficult to prove as correct than it is for something like shell escaping (and people still screw that up too).

The demand for streaming such data from untrusted sources just means it's a 'real' problem instead of a 'hard' problem. My impression is that malicious audio exploits have been more common than with the image libs over recent years. Some numbers might prove that wrong, but 'other' exploits clearly still outnumber both by a fair margin.

That you can't even trust DNS is pointing you where you thought it would anymore doesn't help that a lot either.

Most web browsers and email clients will happily try to load any file that is presented to them as being an image. If they rely on an image library that is vulnerable, then it's game over. And do you really think it's the browser's responsibility to check the image before feeding it to libtiff?

In the same way that it's your responsibility to check that an aircraft is airworthy before you pilot it, I would say yes. If the browser author expects libtiff to be used for such a purpose then certainly it is their responsibility to warrant that it is suitable for it. Anything less might even be deemed negligence, in every sense of that word. Of course they should put those checks into libtiff (or some equivalent) rather than have them in the browser, but that doesn't change who is ultimately responsible for delivering what they have promised unsuspecting people.

Whether you like this responsibility or not, you have to accept it, or else you'll just be a footnote to history.

I have a hunch that the doctrine of WITHOUT WARRANTY OF ANY KIND will outlive all of us as a footnote by a pretty long stretch.

I'd suggest people who require libtiff to be used with untrusted data are the ones who are best placed to be investing in their own self-interest here. There is a very big difference between the proverbial 'fix it yourself' that free software projects are sometimes tarnished with in responding to 'ordinary users' and saying 'clean up your own mess' to a large software house that made marketing promises which weren't grounded in any existing reality. There will be plenty of legitimate and perfectly safe uses for libtiff long after their "don't ask, don't tell" ruse is exposed. When they care enough about their users, that will surely be addressed. I see a measure of inevitability about that too, so I don't think we need to panic excessively.

A list of people who should receive embargoed reports for comment seems like a useful thing to have instead of leaving individuals here as a single 'point of failure' when patches from security auditors need to be reviewed -- but that's as much an issue for the people on the various security teams who are privy to the embargoed information as it is for any particular person here. If Frank was too busy to respond, it seems pretty clear that they failed in not trying to contact other people here before the embargo was lifted too.

I'm sure we'll all do better next time. We always do.

Cheers,
Ron