Vulnerable TIFF

To save people time, here is the "fix" proposed by http://bugzilla.maptools.org/show_bug.cgi?id=2552 (upstream), where it has been declared RESOLVED WONTFIX:

rm /usr/local/bin/gif2tiff

Some basic analysis from me, which you use at your own risk, standard BSD disclaimer applies. If you make no use of that particular tool, just delete it and you are good. If you don't have any way for random remote gif files to be fed into it (i.e. nothing like a web app accepting GIF uploads and then using it to turn them into TIFFs), you are not remotely vulnerable and can mostly relax (but don't go feeding it random GIFs off the net). A local user can't use the vulnerability for privilege escalation (unless you did something crazy and made it setuid, or you give them a way to trick another UID to run it for them on bad input), but could compromise their own account. Reducing permissions on it to restrict its use to trusted people might be a worthwhile step if you have a large number of users and don't want to delete it. The following could be a useful interim compromise to find out if it's used anywhere on your system:

chmod 0 /usr/local/bin/gif2tiff (default perms are 0755, if you need to revert it)

Commentary. Since they (upstream) have the details of the overflow, it seems spectacularly lazy to just delete it. I've not looked at the code, so maybe it is a horrible mess that does need to be euthanised; but that first impression is what it is. If that interpretation is unjust, then this is a good example of why you should always write a paragraph or two justifying/explaining a potentially odd looking decision in response to support or bug tickets.

Last thought, there should be plenty of other options for converting GIFs to TIFFs.
 
kpa said:
Uhm, how is an overflow in a program that is never going to be used as a network server a serious vulnerability? It's not setuid(2) root either.
Click to expand...

Well, someone might be calling it with network input in the middle of a web request handler, for example. Plenty of vulnerabilities get remotely exploited either due to the user having found a way to connect the net into them, or the user being persuaded to run the exploit. The risk with this one shouldn't be terribly high for most people, but it's certainly non-zero and possible for someone to be attacked through it.
 
Murph said:
Well, someone might be calling it with network input in the middle of a web request handler, for example. Plenty of vulnerabilities get remotely exploited either due to the user having found a way to connect the net into them, or the user being persuaded to run the exploit. The risk with this one shouldn't be terribly high for most people, but it's certainly non-zero and possible for someone to be attacked through it.
Click to expand...

That would still result only in gif2tiff crashing and that wouldn't open up any more attack vectors. Denial of service maybe but that wouldn't help the attacker to gain any more surface to attack.
 
kpa said:
That would still result only in gif2tiff crashing and that wouldn't open up any more attack vectors. Denial of service for sure but that wouldn't help the attacker to gain any more surface to attack.
Click to expand...

Overflows can often be turned into remote execution exploits. I certainly wouldn't want to guarantee this one against remote execution in cases where someone has wired network to its input, without taking a much more careful look at it.
 
You must log in or register to reply here.
Back
Top