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). Reproducible: Always Steps to Reproduce:
Upstream looks quite dead...
Sent an email upstream to see what is going to get done regarding this issue.
Upstreams response: =============== 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 properly. 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 [1], but I'm not sure that really fixes the problem, it just avoids this particular exploit. -Rus. [1] 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] zgv-5.8-integer-overflow-fix.diff [from upstream]: 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. -Rus.
Heinrich, You were the last person to bump this package. Please verify/apply patch from upstream. Thanks!
added a new version with this patch as x86
GLSA 200411-12
