qt4 apps broken

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Lars Engblom
This problem is affecting Minitube. Before the workaround, all you get
is an empty window. This workaround makes it possible to search for
clip, but you are still not able to watch them. You only hear the sound.

On 10/09/13 22:50, Stuart Henderson wrote:
> Temporary workaround until we can fix this:
>
> Set QT_X11_NO_MITSHM=1 in the environment
>

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Matthieu Herrb
In reply to this post by Stuart Henderson-6
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.
--
Matthieu Herrb

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

David Coppa
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?

ciao,
David

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Matthieu Herrb
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

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Stuart Henderson
In reply to this post by Lars Engblom
On 2013-10-10, Lars Engblom <[hidden email]> wrote:

> This problem is affecting Minitube. Before the workaround, all you get
> is an empty window. This workaround makes it possible to search for
> clip, but you are still not able to watch them. You only hear the sound.
>
> On 10/09/13 22:50, Stuart Henderson wrote:
>> Temporary workaround until we can fix this:
>>
>> Set QT_X11_NO_MITSHM=1 in the environment
>>
>
>

How does 'ipcs -a' look when playing from Minitube?
This (including video playback in minitube) does work for me and others.


Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Lars Engblom
I using two identically installed computers with different hardware and
at different locations.

I happened at this moment to be infront of the one with radeon
framebuffer and here I get Minitube to play by using the workaround.

The other one is using intel framebuffer and there I was not able to
watch clips. Probably this problem is not related to this brokeness in
QT. It is probably another unrelated bug. I will test this more on the
other computer once I have a chance to put my hands on it.


On 10/11/13 11:49, Stuart Henderson wrote:

> On 2013-10-10, Lars Engblom <[hidden email]> wrote:
>> This problem is affecting Minitube. Before the workaround, all you get
>> is an empty window. This workaround makes it possible to search for
>> clip, but you are still not able to watch them. You only hear the sound.
>>
>> On 10/09/13 22:50, Stuart Henderson wrote:
>>> Temporary workaround until we can fix this:
>>>
>>> Set QT_X11_NO_MITSHM=1 in the environment
>>>
>>
> How does 'ipcs -a' look when playing from Minitube?
> This (including video playback in minitube) does work for me and others.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Stuart Henderson-6
Nothing was committed for this yet, did we settle on a fix for it?

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

Marc Espie-2
On Thu, Oct 24, 2013 at 12:48:06AM +0100, Stuart Henderson wrote:
> Nothing was committed for this yet, did we settle on a fix for it?

I said I was completely happy with the shared memory rights change...

Reply | Threaded
Open this post in threaded view
|

Re: qt4 apps broken

David Coppa
On Thu, Oct 24, 2013 at 10:12 AM, Marc Espie <[hidden email]> wrote:
> On Thu, Oct 24, 2013 at 12:48:06AM +0100, Stuart Henderson wrote:
>> Nothing was committed for this yet, did we settle on a fix for it?
>
> I said I was completely happy with the shared memory rights change...

You can go ahead an commit it. Ok for me too, but cannot commit by myself atm...

12