OpenBSD X11 changes summary for 2016-10-04
==========================================

app                                     lib
xserver                                 

== app =============================================================== 01/03 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/X11/app

app

  ~ cwm/calmwm.h                          ~ cwm/conf.c
  ~ cwm/group.c                           ~ cwm/screen.c
  ~ cwm/xutil.c                           

  > Turn CALMWM_NGROUPS define into variable, ngroups. (okan@)

  ~ cwm/calmwm.h                          ~ cwm/client.c
  ~ cwm/conf.c                            

  > Calculate client nameqlen in client_setname(), the only place it's
  > needed/used. (okan@)

  ~ cwm/calmwm.h                          ~ cwm/screen.c
  ~ cwm/xevents.c                         

  > When removing xrandr regions, ensure clients are within the bounds of
  > the screen; adapted from an ancient diff from Sviatoslav Chagaev. Things
  > in this area will likely change, but put this in so it works now and
  > serves as a reminder. (okan@)

== lib =============================================================== 02/03 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/X11/lib

lib

  ~ libX11/src/FontNames.c                ~ libX11/src/ListExt.c
  ~ libX11/src/ModMap.c                   

  > The validation of server responses avoids out of boundary accesses.
  > From Tobias Stoeckmann / Xorg Securiry adrvisory Oct 4, 2016. (matthieu@)

  ~ libX11/src/GetImage.c                 

  > Validation of server responses in XGetImage()
  > Check if enough bytes were received for specified image type and
  > geometry. Otherwise GetPixel and other functions could trigger an
  > out of boundary read later on.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXfixes/src/Region.c                

  > Integer overflow on illegal server response
  > The 32 bit field "rep.length" is not checked for validity, which allows
  > an integer overflow on 32 bit systems.
  > A malicious server could send INT_MAX as length, which gets multiplied
  > by the size of XRectangle. In that case the client won't read the whole
  > data from server, getting out of sync.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXi/src/XGMotion.c                  ~ libXi/src/XGetBMap.c
  ~ libXi/src/XGetDCtl.c                  ~ libXi/src/XGetFCtl.c
  ~ libXi/src/XGetKMap.c                  ~ libXi/src/XGetMMap.c
  ~ libXi/src/XIQueryDevice.c             ~ libXi/src/XListDev.c
  ~ libXi/src/XOpenDev.c                  ~ libXi/src/XQueryDv.c

  > Properly validate server responses
  > By validating length fields from server responses, out of boundary
  > accesses and endless loops can be mitigated.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXrandr/src/XrrConfig.c             ~ libXrandr/src/XrrCrtc.c
  ~ libXrandr/src/XrrMonitor.c            ~ libXrandr/src/XrrOutput.c
  ~ libXrandr/src/XrrProvider.c           ~ libXrandr/src/XrrScreen.c

  > Avoid out of boundary accesses on illegal responses
  > The responses of the connected X server have to be properly checked
  > to avoid out of boundary accesses that could otherwise be triggered
  > by a malicious server.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXrender/src/Filter.c               

  > Avoid OOB write in XRenderQueryFilters
  > The memory for filter names is reserved right after receiving the reply.
  > After that, filters are iterated and each individual filter name is
  > stored in that reserved memory.
  > The individual name lengths are not checked for validity, which means
  > that a malicious server can reserve less memory than it will write to
  > during each iteration.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXrender/src/Xrender.c              

  > Validate lengths while parsing server data.
  > Individual lengths inside received server data can overflow
  > the previously reserved memory.
  > It is therefore important to validate every single length
  > field to not overflow the previously agreed sum of all invidual
  > length fields.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXtst/src/XRecord.c                 

  > Out of boundary access and endless loop in libXtst
  > A lack of range checks in libXtst allows out of boundary accesses.
  > The checks have to be done in-place here, because it cannot be done
  > without in-depth knowledge of the read data.
  > If XRecordStartOfData, XRecordEndOfData, or XRecordClientDied
  > without a client sequence have attached data, an endless loop would
  > occur. The do-while-loop continues until the current index reaches
  > the end. But in these cases, the current index would not be
  > incremented, leading to an endless processing.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXv/src/Xv.c                        

  > Protocol handling issues in libXv
  > The Xv query functions for adaptors and encodings suffer from out of
  > boundary
  > accesses if a hostile X server sends a maliciously crafted response.
  > A previous fix already checks the received length against fixed values but
  > ignores additional length specifications which are stored inside the
  > received
  > data.
  > These lengths are accessed in a for-loop. The easiest way to guarantee a
  > correct processing is by validating all lengths against the remaining size
  > left before accessing referenced memory.
  > This makes the previously applied check obsolete, therefore I removed it.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libXvMC/src/XvMC.c                    

  > Avoid buffer underflow on empty strings.
  > If an empty string is received from an x-server, do not underrun the
  > buffer by accessing "rep.nameLen - 1" unconditionally, which could end
  > up being -1.
  > From Tobias Stoeckmann / X.Org security advisory Oct 4, 2016 (matthieu@)

  ~ libX11/src/FontNames.c                ~ libX11/src/GetImage.c
  ~ libX11/src/ListExt.c                  ~ libX11/src/ModMap.c
  ~ libXfixes/src/Region.c                ~ libXi/src/XGMotion.c
  ~ libXi/src/XGetBMap.c                  ~ libXi/src/XGetDCtl.c
  ~ libXi/src/XGetFCtl.c                  ~ libXi/src/XGetKMap.c
  ~ libXi/src/XGetMMap.c                  ~ libXi/src/XIQueryDevice.c
  ~ libXi/src/XListDev.c                  ~ libXi/src/XOpenDev.c
  ~ libXi/src/XQueryDv.c                  ~ libXrandr/src/XrrConfig.c
  ~ libXrandr/src/XrrCrtc.c               ~ libXrandr/src/XrrMonitor.c
  ~ libXrandr/src/XrrOutput.c             ~ libXrandr/src/XrrProvider.c
  ~ libXrandr/src/XrrScreen.c             ~ libXrender/src/Filter.c
  ~ libXrender/src/Xrender.c              ~ libXtst/src/XRecord.c
  ~ libXv/src/Xv.c                        ~ libXvMC/src/XvMC.c

  TAGGED OPENBSD_6_0
  > Protocol handling issues in X Window System client libraries
  > X.Org security advisory: October 4, 2016
  > Fix a number of issues in the way various X client libraries handle
  > server responses.
  > Checked by tj@ (matthieu@)

  ~ libX11/src/FontNames.c                ~ libX11/src/GetImage.c
  ~ libX11/src/ListExt.c                  ~ libX11/src/ModMap.c
  ~ libXfixes/src/Region.c                ~ libXi/src/XGMotion.c
  ~ libXi/src/XGetBMap.c                  ~ libXi/src/XGetDCtl.c
  ~ libXi/src/XGetFCtl.c                  ~ libXi/src/XGetKMap.c
  ~ libXi/src/XGetMMap.c                  ~ libXi/src/XIQueryDevice.c
  ~ libXi/src/XListDev.c                  ~ libXi/src/XOpenDev.c
  ~ libXi/src/XQueryDv.c                  ~ libXrandr/src/XrrConfig.c
  ~ libXrandr/src/XrrCrtc.c               ~ libXrandr/src/XrrOutput.c
  ~ libXrandr/src/XrrProvider.c           ~ libXrandr/src/XrrScreen.c
  ~ libXrender/src/Filter.c               ~ libXrender/src/Xrender.c
  ~ libXtst/src/XRecord.c                 ~ libXv/src/Xv.c
  ~ libXvMC/src/XvMC.c                    

  TAGGED OPENBSD_5_9
  > Protocol handling issues in X Window System client libraries
  > X.Org security advisory: October 4, 2016
  > Fix a number of issues in the way various X client libraries handle
  > server responses.
  > Checked by tj@ (matthieu@)

== xserver =========================================================== 03/03 ==

  http://cvsweb.openbsd.org/cgi-bin/cvsweb/X11/xserver

xserver

  ~ Makefile.bsd-wrapper                  

  > ignore chown error (for systems which don't install a Xserver) (deraadt@)

===============================================================================
_______________________________________________
odc mailing list
[email protected]
http://www.squish.net/mailman/listinfo/odc

Reply via email to