[Development] The shmget security fix

[Thiago Macieira]

Starting a thread to discuss the fix and whether its fix is appropriate.

The fix can be divided in two parts:

1) the use of shmget in QSharedMemory to implement the public API of sharing 
memory

2) internal uses of shmget, subdividing into:
 a) internal uses inside Qt only, never with third-party code (mostly QWS)
 b) internal uses that share memory with third-party code (X11 MIT-SHM)

There are two potential problems arising from this change:
 I) a legitimate access by another (non-root) user would stop working
 II) a legitimate access by the same user could fail if the other application 
requests more privileges (so far only found in BSD-type kernels)

I'll deal with each in turn.

1) QSharedMemory

The fix changes the behaviour of public API, restricting all shared memory 
segments to be readable and writeable only by the current user. This prevents 
attackers from reading memory that could be sensitive or, worse, modifying it. 
Since QSharedMemory is a generic API, we simply cannot tell whether the user 
is using it to store/share sensitive information or not, whether spurious 
modifications could lead to crashes or other exploitation vectors.

Moreover, QSharedMemory internally uses QSystemSemaphore to provide locking in 
a way that it's very unlikely that it is used to interoperate with non-Qt 
code. In fact, the QSharedMemory::setNativeKey function was not created until 
Qt 4.8, so we can be certain (to a very high degree) that users of Qt 4.4 
through 4.7 do not try to interoperate. Therefore problem II should not apply.

This leaves problem I: there's simply no way to resolve this situation and fix 
the security issue at the same time, without the addition of new API. 
Therefore the security team and the maintainer of the code in question (read: 
me) agreed that the potential drawbacks are outweighed by the increased 
security.

2.a) internal uses of shmget with no third-party interaction

Since all endpoints of the connection are controlled by Qt, there's no issue 
of incompatibility (problem II). More, the sections of code creating the 
shared memory segments in QWS were not affected by the fix anyway -- only the 
qvfb tool. Therefore, we conclude that problem I cannot apply.

2.b) internal uses of shmget with third-party interaction

The third party in question could be running as a different user or could use 
different attach modes. In fact, as reported by the Debian maintainer (Sune 
Vuorela), the X server *does* try to shmget with more permissions, which 
causes the call to fail when run on FreeBSD. So we conclude that problem I 
does apply for those systems.

After analysing the situation, we concluded that it was acceptable for the X 
server to fail to get to the shared memory segment. The protocol would 
automatically fall back to transferring the image in question over the socket. 
Therefore, the only impact would be of a reduced performance and on Linux 
systems, that would be a very minor corner case. There is no loss of 
functionality.

Conclusion:

There are risks associated with this fix, including a change of behaviour. 
Those are well understood and are deemed acceptable in face of the fix itself.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130220/07eb7016/attachment.sig>