On Thu, Oct 10, 2013 at 02:55:39PM +0200, David Coppa wrote: > On Thu, 10 Oct 2013, Matthieu Herrb wrote: > > > On Wed, Oct 09, 2013 at 08:51:54PM +0100, Stuart Henderson wrote: > > > > > -------------------- > > > > > - Change all shmget calls to user-only memory (security) > > > > > > > > > > So yes, the problem is due to qt4, which use more strict permissions > > > > > for shmget. > > > > > > > > The aforementioned change was done to fix CVE-2013-0254. > > > > > > > > Here's the commit: > > > > > > > > https://qt.gitorious.org/qt/qt/commit/20b26bdb3dd5e46b01b9a7e1ce8342074df3c89c?format=patch > > > > > > > > So what now? Revert a security fix? > > > > > > Debian ran into this with kfreebsd, they have applied this to xserver > > > > > > http://people.debian.org/~jcristau/kbsd-peercred.diff > > > > This is related, but not the same issue. On other systems the X server > > is still running as root and thus has full access to shared memory > > segments. > > > > Since a client can pass a shm id to the X server and as it to render > > the image contained herein, this would allow any X client to read > > arbitrary shms on which they have normally no access: > > http://www.securityfocus.com/bid/4396 > > > > So the X server has to re-implement access() to check if the uid/gid > > of the client asking the X server to access a given shmid have the > > required privilege or not. And thus in this case it's important to > > have a working getpeercred() or similar to do the check. > > > > So this won't help in our case. > > So, from your pov, reverting: > > https://qt.gitorious.org/qt/qt/commit/20b26bdb3dd5e46b01b9a7e1ce8342074df3c89c?format=patch > > and go back to the 4.8.2 situation, would it be a big security issue > for us?
I don't think it's a big security issue. Applications that create a shared memory segment and pass its id to the X server should not store secret that there, as they can't trust the X server anyways. Trying to protect them with mode 600 doesn't make much sense to me. The only risk is if Qt also uses shms for other stuff and has set a fixed access mode in some abstraction layer so that the mode for Xshm has to be the same as for other kind of communications, it will expose those other shms again. ie I'm not sure if all calls to shmget have to be backed out, or only the ones used to create SHMs that are later used in the Xsmh extension. >From the function names, I'd say onyl the 3 first hunks need to be reverted (qt_create_mitshm_buffer, QXcbShmImage, QXlibWindowSurface::resizeShmImage) -- Matthieu Herrb
