Re: [ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
Hi, On 23 May 2013 23:36, Alan Coopersmith alan.coopersm...@oracle.com wrote: I still agree with most of my quotes that got captured there, including the one blaming daniels for not saving us from all manner of XKB woes. (I know, XKB2 would fix it all, if only the laptop was returned by the thief we all curse.) Well, yes-ish. To actually properly fix the problem, you'd have to go back in time and stop SGI from encoding XKB into the Xlib ABI! ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
Hi, On 23 May 2013 23:36, Alan Coopersmith alan.coopersm...@oracle.com wrote: I still agree with most of my quotes that got captured there, including the one blaming daniels for not saving us from all manner of XKB woes. (I know, XKB2 would fix it all, if only the laptop was returned by the thief we all curse.) Well, yes-ish. To actually properly fix the problem, you'd have to go back in time and stop SGI from encoding XKB into the Xlib ABI! ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
On 05/23/13 08:05 AM, Alan Coopersmith wrote: X.Org Security Advisory: May 23, 2013 Protocol handling issues in X Window System client libraries Description: Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues. BTW, I see that Ilja also mentioned these (without giving full details on the holes) in his recent CanSecWest talk, which is an interesting read: http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Security%20-%20Ilja%20van%20Sprundel.ppt I still agree with most of my quotes that got captured there, including the one blaming daniels for not saving us from all manner of XKB woes. (I know, XKB2 would fix it all, if only the laptop was returned by the thief we all curse.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
X.Org Security Advisory: May 23, 2013 Protocol handling issues in X Window System client libraries Description: Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues. Most of these issues stem from the client libraries trusting the server to send correct protocol data, and not verifying that the values will not overflow or cause other damage. Most of the time X clients servers are run by the same user, with the server more privileged from the clients, so this is not a problem, but there are scenarios in which a privileged client can be connected to an unprivileged server, for instance, connecting a setuid X client (such as a screen lock program) to a virtual X server (such as Xvfb or Xephyr) which the user has modified to return invalid data, potentially allowing the user to escalate their privileges. The X.Org security team would like to take this opportunity to remind X client authors that current best practices suggest separating code that requires privileges from the GUI, to reduce the attack surface of issues like this. The vulnerabilities include: - integer overflows calculating memory needs for replies These calls do not check that their calculations for how much memory is needed to handle the returned data have not overflowed, so can result in allocating too little memory and then writing the returned data past the end of the allocated buffer. * CVE-2013-1981: libX11 1.5.99.901 (1.6 RC1) and earlier Affected functions: XQueryFont(), _XF86BigfontQueryFont(), XListFontsWithInfo(), XGetMotionEvents(), XListHosts(), XGetModifierMapping(), XGetPointerMapping(), XGetKeyboardMapping(), XGetWindowProperty(), XGetImage() * CVE-2013-1982: libXext 1.3.1 and earlier Affected functions: XcupGetReservedColormapEntries(), XcupStoreColors(), XdbeGetVisualInfo(), XeviGetVisualInfo(), XShapeGetRectangles(), XSyncListSystemCounters() * CVE-2013-1983: libXfixes 5.0 and earlier Affected functions: XFixesGetCursorImage() * CVE-2013-1984: libXi 1.7.1 and earlier Affected functions: XGetDeviceControl(), XGetFeedbackControl(), XGetDeviceDontPropagateList(), XGetDeviceMotionEvents(), XIGetProperty(), XIGetSelectedEvents(), XGetDeviceProperties(), XListInputDevices() * CVE-2013-1985: libXinerama 1.1.2 and earlier Affected functions: XineramaQueryScreens() * CVE-2013-2062: libXp 1.0.1 and earlier Affected functions: XpGetAttributes(), XpGetOneAttribute(), XpGetPrinterList(), XpQueryScreens() * CVE-2013-1986: libXrandr 1.4.0 and earlier Affected functions: XRRQueryOutputProperty(), XRRQueryProviderProperty() [XRRQueryProviderProperty() was introduced in libXrandr 1.4.0 and is not found in 1.3.2 and older releases.] * CVE-2013-1987: libXrender 0.9.7 and earlier Affected functions: XRenderQueryFilters(), XRenderQueryFormats(), XRenderQueryPictIndexValues() * CVE-2013-1988: libXRes 1.0.6 and earlier Affected functions: XResQueryClients(), XResQueryClientResources() * CVE-2013-2063: libXtst 1.2.1 and earlier Affected functions: XRecordGetContext() * CVE-2013-1989: libXv 1.0.7 and earlier Affected functions: XvQueryPortAttributes(), XvListImageFormats(), XvCreateImage() * CVE-2013-1990: libXvMC 1.0.7 and earlier Affected functions: XvMCListSurfaceTypes(), XvMCListSubpictureTypes() * CVE-2013-1991: libXxf86dga 1.1.3 and earlier Affected functions: XDGAQueryModes(), XDGASetMode() * CVE-2013-1992: libdmx 1.1.2 and earlier Affected functions: DMXGetScreenAttributes(), DMXGetWindowAttributes(), DMXGetInputAttributes() * CVE-2013-2064: libxcb 1.9 and earlier Affected functions: read_packet() * CVE-2013-1993: libGLX in Mesa 9.1.1 and earlier Affected functions: XF86DRIOpenConnection(), XF86DRIGetClientDriverName() * CVE-2013-1994: libchromeXvMC libchromeXvMCPro in openChrome 0.3.2 and earlier Affected functions: uniDRIOpenConnection(), uniDRIGetClientDriverName() - sign extension issues calculating memory needs for replies These calls do not check that their calculations for how much memory is needed to handle the returned data have not had sign extension issues when converting smaller integer types to larger ones, leading to negative numbers being used in memory size calculations that can result in allocating too little memory and then writing the returned data past the end of the allocated buffer. * CVE-2013-1995: libXi 1.7.1 and earlier Affected
Re: [ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
On Thu, 2013-05-23 at 08:05 -0700, Alan Coopersmith wrote: X.Org Security Advisory: May 23, 2013 Protocol handling issues in X Window System client libraries For what it's worth, this update just landed in the gnome-ostree continuous integration system, and gnome-settings-daemon is no longer able to upload keyboard descriptions: (gnome-settings-daemon:577): keyboard-plugin-WARNING **: Couldn't upload new XKB keyboard description [xcb] Extra reply data still left in queue [xcb] This is most likely caused by a broken X extension library [xcb] Aborting, sorry about that. gnome-settings-daemon: ../../src/xcb_io.c:576: _XReply: Assertion `!xcb_xlib_extra_reply_data_left' failed. Relevant code: https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/keyboard/gsd-keyboard-manager.c#n664 I'm investigating this now. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
On 05/23/13 08:05 AM, Alan Coopersmith wrote: X.Org Security Advisory: May 23, 2013 Protocol handling issues in X Window System client libraries Description: Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues. BTW, I see that Ilja also mentioned these (without giving full details on the holes) in his recent CanSecWest talk, which is an interesting read: http://cansecwest.com/slides/2013/Assessing%20the%20Linux%20Desktop%20Security%20-%20Ilja%20van%20Sprundel.ppt I still agree with most of my quotes that got captured there, including the one blaming daniels for not saving us from all manner of XKB woes. (I know, XKB2 would fix it all, if only the laptop was returned by the thief we all curse.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X Window System client libraries
X.Org Security Advisory: May 23, 2013 Protocol handling issues in X Window System client libraries Description: Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues. Most of these issues stem from the client libraries trusting the server to send correct protocol data, and not verifying that the values will not overflow or cause other damage. Most of the time X clients servers are run by the same user, with the server more privileged from the clients, so this is not a problem, but there are scenarios in which a privileged client can be connected to an unprivileged server, for instance, connecting a setuid X client (such as a screen lock program) to a virtual X server (such as Xvfb or Xephyr) which the user has modified to return invalid data, potentially allowing the user to escalate their privileges. The X.Org security team would like to take this opportunity to remind X client authors that current best practices suggest separating code that requires privileges from the GUI, to reduce the attack surface of issues like this. The vulnerabilities include: - integer overflows calculating memory needs for replies These calls do not check that their calculations for how much memory is needed to handle the returned data have not overflowed, so can result in allocating too little memory and then writing the returned data past the end of the allocated buffer. * CVE-2013-1981: libX11 1.5.99.901 (1.6 RC1) and earlier Affected functions: XQueryFont(), _XF86BigfontQueryFont(), XListFontsWithInfo(), XGetMotionEvents(), XListHosts(), XGetModifierMapping(), XGetPointerMapping(), XGetKeyboardMapping(), XGetWindowProperty(), XGetImage() * CVE-2013-1982: libXext 1.3.1 and earlier Affected functions: XcupGetReservedColormapEntries(), XcupStoreColors(), XdbeGetVisualInfo(), XeviGetVisualInfo(), XShapeGetRectangles(), XSyncListSystemCounters() * CVE-2013-1983: libXfixes 5.0 and earlier Affected functions: XFixesGetCursorImage() * CVE-2013-1984: libXi 1.7.1 and earlier Affected functions: XGetDeviceControl(), XGetFeedbackControl(), XGetDeviceDontPropagateList(), XGetDeviceMotionEvents(), XIGetProperty(), XIGetSelectedEvents(), XGetDeviceProperties(), XListInputDevices() * CVE-2013-1985: libXinerama 1.1.2 and earlier Affected functions: XineramaQueryScreens() * CVE-2013-2062: libXp 1.0.1 and earlier Affected functions: XpGetAttributes(), XpGetOneAttribute(), XpGetPrinterList(), XpQueryScreens() * CVE-2013-1986: libXrandr 1.4.0 and earlier Affected functions: XRRQueryOutputProperty(), XRRQueryProviderProperty() [XRRQueryProviderProperty() was introduced in libXrandr 1.4.0 and is not found in 1.3.2 and older releases.] * CVE-2013-1987: libXrender 0.9.7 and earlier Affected functions: XRenderQueryFilters(), XRenderQueryFormats(), XRenderQueryPictIndexValues() * CVE-2013-1988: libXRes 1.0.6 and earlier Affected functions: XResQueryClients(), XResQueryClientResources() * CVE-2013-2063: libXtst 1.2.1 and earlier Affected functions: XRecordGetContext() * CVE-2013-1989: libXv 1.0.7 and earlier Affected functions: XvQueryPortAttributes(), XvListImageFormats(), XvCreateImage() * CVE-2013-1990: libXvMC 1.0.7 and earlier Affected functions: XvMCListSurfaceTypes(), XvMCListSubpictureTypes() * CVE-2013-1991: libXxf86dga 1.1.3 and earlier Affected functions: XDGAQueryModes(), XDGASetMode() * CVE-2013-1992: libdmx 1.1.2 and earlier Affected functions: DMXGetScreenAttributes(), DMXGetWindowAttributes(), DMXGetInputAttributes() * CVE-2013-2064: libxcb 1.9 and earlier Affected functions: read_packet() * CVE-2013-1993: libGLX in Mesa 9.1.1 and earlier Affected functions: XF86DRIOpenConnection(), XF86DRIGetClientDriverName() * CVE-2013-1994: libchromeXvMC libchromeXvMCPro in openChrome 0.3.2 and earlier Affected functions: uniDRIOpenConnection(), uniDRIGetClientDriverName() - sign extension issues calculating memory needs for replies These calls do not check that their calculations for how much memory is needed to handle the returned data have not had sign extension issues when converting smaller integer types to larger ones, leading to negative numbers being used in memory size calculations that can result in allocating too little memory and then writing the returned data past the end of the allocated buffer. * CVE-2013-1995: libXi 1.7.1 and earlier Affected
