On Thu, Jun 13, 2002 at 05:48:58PM +0200, Raphaël Quinet wrote: > I don't think that the problem is so serious. It can only be > exploited locally and AFAIK it does not open any significant security > holes because the shared memory area is only used for exchanging image > tiles between the plug-ins and the core. So the only thing that could > be done by a local attacker is to insert some nasty stuff in the image > that is being processed by a plug-in, assuming that they win the race > between the core and the plug-in. The bug should be fixed, but the > window of opportunity for malicious uses of this shared memory segment > seems to be rather small so it does not deserve any big announcement. It is a security issue anyways. It could be exploited in fun ways. Say, there are plugins written in interpreted languages. If they assume that the shared memory is safe, they might be tricked into interpreting code (after all, we've already seen buffer overflows in jpeg, so this is not at all theoretical). > Unfortunately, I think that fixing this bug may introduce some new > problems: some plug-ins may run under a different user id than the > main program. For example, xscanimage may be installed with a setuid > bit on some systems if this is required in order to access the > scanner. I don't know how the real and effective user id are used in > this case, but this may prevent the plug-in from running correctly. Fix the problems, then. If xscanimage is setuid, then it can switch its effective id to be able to access the segment. Let me remind you that, with unix semantics, the rights are only checked at open, and are then attached to the file descriptor, even if you later lose your privileges. > Also, I think that some old systems (AIX? HP-UX?) had problems with > shared memory segments unless they were created with the mode 777. > This is very vague and I cannot find any information about that, so > maybe this is just a brain fart on my part. This is quite possible, but it is no excuse to keep a security hole around. In the worst case, write a configure test, and resort to mode 777 only if nothing else works. Again, no reason to expose sane systems to security holes elsewhere. > In any case, I don't think that we should be too fast for releasing > this patch because it may cause more problems than it solves. We > really need more testing and feedback from users of various UN*X > systems, especially those who have to run some plug-ins setuid in > order to access some special devices or files. If you start dealing with such problems in this way, you'll never get things solved. The only way to ensure plugin issues get fixed. In any case, if a plugin needs to be setuid, then it had better be written by somewhat security-conscious people (or you've got a whole larger set of problems...), so fixing a shared memory ownership issue on that end is going to be a breeze.
