This post claims multiple overflows in 5.5 (which he incorrectly cites as the latest version). We need to confirm or deny that this exists in our version (5.7-r1) or the latest version (5.8). This package is only marked for x86. Presumably, the results of a sucessful exploit would be code execution as the user enticed to view the malicious picture file (that appears to be the exploit path, but he is unclear).
Steps to Reproduce:
Upstream looks quite dead...
Sent an email upstream to see what is going to get done regarding this issue.
Thanks, I hadn't seen that. One thing to say briefly about the
advisory is that 5.5 isn't the current version of zgv, 5.8 is. But I
don't think the problems have been fixed.
Firstly, here's how I see this. As described in the file "SECURITY"
that comes with zgv, it should be impossible to get a root shell with
this sort of attack because of the way setuid() works, as zgv is only
setuid root briefly when it starts up, and doesn't read any pictures
in that time. Also, zgv checks that the user is logged in at the
console before it reads any pictures.
So as I understand it this is an exploit which could be used to run
arbitrary commands as the user at the console when they view a certain
image, say when using zgv with lynx. Though obviously this is still
pretty bad. :-(
The problem with fixing it is that I'd need to add checks while
generating the image in memory that there's room for it - which really
should have occurred to me at the time, at least for relatively recent
additions like the prf reader, but there it is. This would have to be
done separately for each format, and unless I'm missing something it
seems annoyingly tough because with compression etc. you can't (or
shouldn't) trust the specified image dimensions even if they *don't*
lead to an overflow. I suppose it would mean a pointer boundary check
for every single byte written (to the image in memory) for every
single format supported.
Probably the worst problem is with TIFF, as libtiff is responsible for
reading the entire image there, so I'm not sure how I could fix that
I assume this general issue has affected other programs too, do you
have any idea how it was tackled in those cases? I mean, some of the
most obvious attacks could be quite trivially avoided by just refusing
to view images claiming to be larger than a certain width/height ,
but I'm not sure that really fixes the problem, it just avoids this
 Or for the XPM colours case (the one actually exploited), limiting
"ncols" to, say, 16777216 (2^24).
Anyone have any ideas for a response, or where to go from here?
Created attachment 43076 [details, diff]
I've put together the relatively crude width/height-checking fix I
hinted at before, and that's attached (I'll also be putting it up on
zgv's webpage soon). This *should* fix the overflow problems referred
to in the advisory - and it does seem to. The patch also includes a
GIF reader fix. It's relative to zgv 5.8, but shouldn't be hard to
adapt to earlier versions if necessary.
You were the last person to bump this package. Please verify/apply patch from upstream.
added a new version with this patch as x86