x2go-dev

x2go-dev@lists.x2go.org

2 participants
5403 discussions

Re: [X2Go-Dev] [X2Go-Commits] [nx-libs] 44/52: glx: Be more strict about rejecting invalid image sizes [CVE-2014-8093 2/6]
by Mihai Moldovan 15 Feb '15

15 Feb '15

On 14.02.2015 05:47 PM, git-admin(a)x2go.org wrote: > This is an automated email from the git hooks/post-receive script. > > x2go pushed a commit to branch 3.6.x > in repository nx-libs. > > commit cdf0c3e65670c797a4fd0617d44d2bdff4011815 > Author: Adam Jackson <ajax(a)redhat.com> > Date: Mon Nov 10 12:13:37 2014 -0500 > > glx: Be more strict about rejecting invalid image sizes [CVE-2014-8093 2/6] > > Before this we'd just clamp the image size to 0, which was just > hideously stupid; if the parameters were such that they'd overflow an > integer, you'd allocate a small buffer, then pass huge values into (say) > ReadPixels, and now you're scribbling over arbitrary server memory. > > v2: backport to nx-libs 3.6.x (Mike DePaulo) > > Reviewed-by: Keith Packard <keithp(a)keithp.com> > Reviewed-by: Julien Cristau <jcristau(a)debian.org> > Reviewed-by: Michal Srb <msrb(a)suse.com> > Reviewed-by: Andy Ritger <aritger(a)nvidia.com> > Signed-off-by: Adam Jackson <ajax(a)redhat.com> > Signed-off-by: Alan Coopersmith <alan.coopersmith(a)oracle.com> > Signed-off-by: Fedora X Ninjas <x(a)fedoraproject.org> > Signed-off-by: Dave Airlie <airlied(a)redhat.com> > --- > nx-X11/programs/Xserver/GL/glx/singlepix.c | 14 +++++++------- > nx-X11/programs/Xserver/GL/glx/singlepixswap.c | 14 +++++++------- > 2 files changed, 14 insertions(+), 14 deletions(-) > > diff --git a/nx-X11/programs/Xserver/GL/glx/singlepix.c b/nx-X11/programs/Xserver/GL/glx/singlepix.c > index 845c46a..be804d8 100644 > --- a/nx-X11/programs/Xserver/GL/glx/singlepix.c > +++ b/nx-X11/programs/Xserver/GL/glx/singlepix.c > @@ -70,7 +70,7 @@ int __glXDisp_ReadPixels(__GLXclientState *cl, GLbyte *pc) > swapBytes = *(GLboolean *)(pc + 24); > lsbFirst = *(GLboolean *)(pc + 25); > compsize = __glReadPixels_size(format,type,width,height); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, swapBytes); > glPixelStorei(GL_PACK_LSB_FIRST, lsbFirst); > @@ -130,7 +130,7 @@ int __glXDisp_GetTexImage(__GLXclientState *cl, GLbyte *pc) > * are illegal, but then width, height, and depth would still be zero anyway. > */ > compsize = __glGetTexImage_size(target,level,format,type,width,height,depth); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, swapBytes); > __GLX_GET_ANSWER_BUFFER(answer,cl,compsize,1); > @@ -227,7 +227,7 @@ int __glXDisp_GetSeparableFilter(__GLXclientState *cl, GLbyte *pc) > compsize = __glGetTexImage_size(target,1,format,type,width,1,1); > compsize2 = __glGetTexImage_size(target,1,format,type,height,1,1); > > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > if (compsize2 < 0) compsize2 = 0; NO ACTION NEEDED: This is bad, bad, bad. compsize is checked, but compsize2 completely ignored. However, a later patch fixes this, so we are good. > compsize = __GLX_PAD(compsize); > compsize2 = __GLX_PAD(compsize2); > @@ -291,7 +291,7 @@ int __glXDisp_GetConvolutionFilter(__GLXclientState *cl, GLbyte *pc) > * are illegal, but then width and height would still be zero anyway. > */ > compsize = __glGetTexImage_size(target,1,format,type,width,height,1); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, swapBytes); > __GLX_GET_ANSWER_BUFFER(answer,cl,compsize,1); > @@ -346,7 +346,7 @@ int __glXDisp_GetHistogram(__GLXclientState *cl, GLbyte *pc) > * are illegal, but then width would still be zero anyway. > */ > compsize = __glGetTexImage_size(target,1,format,type,width,1,1); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, swapBytes); > __GLX_GET_ANSWER_BUFFER(answer,cl,compsize,1); > @@ -389,7 +389,7 @@ int __glXDisp_GetMinmax(__GLXclientState *cl, GLbyte *pc) > reset = *(GLboolean *)(pc + 13); > > compsize = __glGetTexImage_size(target,1,format,type,2,1,1); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, swapBytes); > __GLX_GET_ANSWER_BUFFER(answer,cl,compsize,1); > @@ -436,7 +436,7 @@ int __glXDisp_GetColorTable(__GLXclientState *cl, GLbyte *pc) > * are illegal, but then width would still be zero anyway. > */ > compsize = __glGetTexImage_size(target,1,format,type,width,1,1); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, swapBytes); > __GLX_GET_ANSWER_BUFFER(answer,cl,compsize,1); > diff --git a/nx-X11/programs/Xserver/GL/glx/singlepixswap.c b/nx-X11/programs/Xserver/GL/glx/singlepixswap.c > index ff68ece..cdc6f16 100644 > --- a/nx-X11/programs/Xserver/GL/glx/singlepixswap.c > +++ b/nx-X11/programs/Xserver/GL/glx/singlepixswap.c > @@ -79,7 +79,7 @@ int __glXDispSwap_ReadPixels(__GLXclientState *cl, GLbyte *pc) > swapBytes = *(GLboolean *)(pc + 24); > lsbFirst = *(GLboolean *)(pc + 25); > compsize = __glReadPixels_size(format,type,width,height); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, !swapBytes); > glPixelStorei(GL_PACK_LSB_FIRST, lsbFirst); > @@ -148,7 +148,7 @@ int __glXDispSwap_GetTexImage(__GLXclientState *cl, GLbyte *pc) > * are illegal, but then width, height, and depth would still be zero anyway. > */ > compsize = __glGetTexImage_size(target,level,format,type,width,height,depth); > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > > glPixelStorei(GL_PACK_SWAP_BYTES, !swapBytes); > __GLX_GET_ANSWER_BUFFER(answer,cl,compsize,1); > @@ -257,7 +257,7 @@ int __glXDispSwap_GetSeparableFilter(__GLXclientState *cl, GLbyte *pc) > compsize = __glGetTexImage_size(target,1,format,type,width,1,1); > compsize2 = __glGetTexImage_size(target,1,format,type,height,1,1); > > - if (compsize < 0) compsize = 0; > + if (compsize < 0) return BadLength; > if (compsize2 < 0) compsize2 = 0; NO ACTION NEEDED: Same problem here. Everything else in this patch looks fine.

1 0

Re: [X2Go-Dev] [X2Go-Commits] [nx-libs] 29/52: CVE-2014-0210: unvalidated length fields in fs_read_list_info() from xorg/lib/libXfont commit d338f81df1e188eb16e1d6aeea7f4800f89c1218
by Mihai Moldovan 15 Feb '15

15 Feb '15

On 14.02.2015 05:47 PM, git-admin(a)x2go.org wrote: > This is an automated email from the git hooks/post-receive script. > > x2go pushed a commit to branch 3.6.x > in repository nx-libs. > > commit b65259bf3bcca15b5069cb7a6c06f95a40f79813 > Author: Mike DePaulo <mikedep333(a)gmail.com> > Date: Sun Feb 8 22:38:32 2015 -0500 > > CVE-2014-0210: unvalidated length fields in fs_read_list_info() from xorg/lib/libXfont commit d338f81df1e188eb16e1d6aeea7f4800f89c1218 > > fs_read_list_info() parses a reply from the font server. The reply > contains a number of additional data items with embedded length or > count fields, none of which are validated. This can cause out of > bound reads when looping over these items in the reply. > --- > nx-X11/lib/font/fc/fserve.c | 56 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 55 insertions(+), 1 deletion(-) > > diff --git a/nx-X11/lib/font/fc/fserve.c b/nx-X11/lib/font/fc/fserve.c > index 60d9017..6ba3ad4 100644 > --- a/nx-X11/lib/font/fc/fserve.c > +++ b/nx-X11/lib/font/fc/fserve.c > @@ -2500,6 +2500,7 @@ fs_read_list_info(FontPathElementPtr fpe, FSBlockDataPtr blockrec) > FSBlockedListInfoPtr binfo = (FSBlockedListInfoPtr) blockrec->data; > fsListFontsWithXInfoReply *rep; > char *buf; > + long bufleft; Same here. Everything else in this patch looks OK.

1 0

Re: [X2Go-Dev] [X2Go-Commits] [nx-libs] 27/52: CVE-2014-0210: unvalidated length fields in fs_read_glyphs() from xorg/lib/libXfont commit 520683652564c2a4e42328ae23eef9bb63271565
by Mihai Moldovan 15 Feb '15

15 Feb '15

On 14.02.2015 05:47 PM, git-admin(a)x2go.org wrote: > This is an automated email from the git hooks/post-receive script. > > x2go pushed a commit to branch 3.6.x > in repository nx-libs. > > commit ece51493f1d970f45e53588e33a700464a42fbab > Author: Mike DePaulo <mikedep333(a)gmail.com> > Date: Sun Feb 8 22:27:47 2015 -0500 > > CVE-2014-0210: unvalidated length fields in fs_read_glyphs() from xorg/lib/libXfont commit 520683652564c2a4e42328ae23eef9bb63271565 > > fs_read_glyphs() parses a reply from the font server. The reply > contains embedded length fields, none of which are validated. > This can cause out of bound reads when looping over the glyph > bitmaps in the reply. > --- > nx-X11/lib/font/fc/fserve.c | 29 ++++++++++++++++++++++++++++- > 1 file changed, 28 insertions(+), 1 deletion(-) > > diff --git a/nx-X11/lib/font/fc/fserve.c b/nx-X11/lib/font/fc/fserve.c > index 79de4f3..26218e5 100644 > --- a/nx-X11/lib/font/fc/fserve.c > +++ b/nx-X11/lib/font/fc/fserve.c > @@ -1916,6 +1916,7 @@ fs_read_glyphs(FontPathElementPtr fpe, FSBlockDataPtr blockrec) > FontInfoPtr pfi = &pfont->info; > fsQueryXBitmaps16Reply *rep; > char *buf; > + long bufleft; /* length of reply left to use */ I'd also initialize this: long bufleft = 0; Everything else here is OK.

1 0

Re: [X2Go-Dev] Fixes for 2011-2014 X.org CVEs and potential regressions in nx-libs
by Michael DePaulo 15 Feb '15

15 Feb '15

2015-02-15 8:31 GMT-05:00 Mike DePaulo <mikedep333(a)gmail.com>: > bQBuWYZZrHSq5sOQcsDIQWu+r/7qcjvr+dyRT+OpvosVpZFpWXshb9a7gEBqB85/ Sorry, please ignore that email. I told ThunderBird with the EnigMail extension to send the email about CVEs being mitigated by "-nolisten TCP" twice because the 1st time produced an error message. For whatever reason, the 1st time it was sent, but it was sent encrypted. The 2nd time, it was sent successfully, and was signed.

1 0

Re: [X2Go-Dev] Fixes for 2011-2014 X.org CVEs and potential regressions in nx-libs
by Mike DePaulo 15 Feb '15

15 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Feb 14, 2015 at 12:43 PM, Mike DePaulo <mikedep333(a)gmail.com> wrote: > ... > https://docs.google.com/spreadsheets/d/1WeneRYO2TkXYOl5J0WozThsLkreF1DiuJAv… > > > ... > > Also, note that by default, X2GO launches nxagent (the nx-libs X > server) with "-nolisten tcp". This is configurable in > /etc/x2go/x2goagent.options . This setting mitigates many of the > vulnerabilities by preventing nxagent from ever talking to X11 > clients not running on the X2Go Server. I will now be determining > which vulnerabilities it does mitigate. Most CVEs are mitigated by "-nolisten TCP", or are N/A because the CVEs can only be exploited by local X11 clients (X11 applications) anyway. "-nolisten TCP" is especially important for mitigating CVE-2014-8091 because an X11 client need not be authenticated to exploit it. An exploit would result in nxagent (and thus your X2Go session) crashing. (In layman's terms, unless you kept "-nolisten TCP" set, someone on the network can crash every X2Go session running on an X2Go server.) 2 CVEs are not mitigated by "-nolisten TCP": 2014-0210 CVE-2014-0211 A malicious remote X Font Server can trigger these vulnerabilities, even when the X11 clients are running locally on the X2Go server. - -Mike#2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlTgn+8ACgkQIFy22CVQsitHFwD/X2v6kUmf1+vVGbG5gvYMAT7d YlZ5Ks62wwK6eSutNR0BAJAI7H83e8TBtIc3vs0OIZamn3tCfBwJ3WZsjwOWT7WC =eykp -----END PGP SIGNATURE-----

1 0

Fixes for 2011-2014 X.org CVEs and potential regressions in nx-libs
by Mike DePaulo 14 Feb '15

14 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello X2Go Developers, Over the last few weeks, I have been auditing nx-libs against all the vulnerabilities (CVEs) in X.org 6.9.0. nx-libs 3.5.0 (released by NoMachine in 2011) contains a fork of X.org 6.9.0 (released in December 2005). So our concern was that a large percentage of the X.org vulnerabilities announced since X.org 6.9.0 affect nx-libs. I wrote a spreadsheet with the results of my audit here. Note that I have not actually tested whether the vulnerabilities affect us. For example, I have not tried out any proof-of-concept exploits. But if the vulnerable code is present, and the vulnerable code is not totally ignored by nx-libs, then I assumed that the vulnerability affects nx-libs. The only exception is CVE-2013-1940; I inferred that it does not affect us because it only affects VT switching on Linux, and nx-libs does not use VTs. https://docs.google.com/spreadsheets/d/1WeneRYO2TkXYOl5J0WozThsLkreF1DiuJAv… To summarize the results: 1. Some vulnerabilities do not affect us for various reasons. Often because the code was removed by NoMachine. 2. NoMachine did a very good job of patching the vulnerabilities. The earliest vulnerability that was unpatched, CVE-2011-2895, was announced on 2011-08-10. 3. The majority of the vulnerabilities after 2011-08-10 did affect nx-libs 3.5.0.x and nx-libs 3.6.x. I fixed these and the fixes are now in git. See details below. As I audited nx-libs, I fixed each vulnerability. Before the December 2014 vulnerabilities, I backported the commit/patch from upstream X.org. For the December 2014 vulnerabilities, which were numerous and whose patches/commits were hard to merge, I obtained the patches from RHEL5 instead. RHEL 5 uses X.org 7.1 (xorg-server 1.1.1), so their patches were easier to apply to nx-libs. I am a beginner at programming in C. So I asked Mike#1 (Mike Gabriel) to review my work. He did, and did not find any issues. I still welcome further review though. Mike#1 committed my work to the 3.6.x branch: 1st commit: http://code.x2go.org/gitweb?p=nx-libs.git;a=commit;h=af55da1e9c1a6a352b2482… last (40th) commit: http://code.x2go.org/gitweb?p=nx-libs.git;a=commit;h=1ea1cd8c4f93b0c03e5b34… He also committed it to the 3.5.0.x branch as one commit with 40 patch files: http://code.x2go.org/gitweb?p=nx-libs.git;a=commitdiff;h=4587881130db36125c… However, because many lines of code have been changed, Mike#1 and I agreed that we will not release 3.5.0.29 with these fixes immediately. Instead, we will let users/developers do some testing to see if any regressions were introduced. Also, note that by default, X2GO launches nxagent (the nx-libs X server) with "-nolisten tcp". This is configurable in /etc/x2go/x2goagent.options . This setting mitigates many of the vulnerabilities by preventing nxagent from ever talking to X11 clients not running on the X2Go Server. I will now be determining which vulnerabilities it does mitigate. - -Mike#2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iF4EAREIAAYFAlTfiSUACgkQIFy22CVQsitDXAEAlte83RMq3iy218Q7zXggAb0R XpvCpQYOYnaZenHPqQsBAMVfH8olUE1mh6DNfTgeC2909c1t4JDAjx3pSEdSDdL5 =mUvD -----END PGP SIGNATURE-----

1 0

Bug#785: 785
by Sergey Savko 13 Feb '15

13 Feb '15

Yes, it's work. Thank you. This bug does not appear after turning on this option? https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/985202 ----- Исходное сообщение ----- От: "Ulrich Sibiller" <uli42(a)gmx.de> Кому: "Sergey Savko" <savko(a)tophouse.ru> Отправленные: Пятница, 13 Февраль 2015 г 0:27:55 Тема: Re: 785 Ok, please enable the XFIXES extension. This can be done in /etc/x2go/x2goagent.options Ensure that you find +extension XFIXES in there: X2GO_NXAGENT_DEFAULT_OPTIONS+=" +extension XFIXES" Uli On Thu, Feb 12, 2015 at 9:33 PM, Sergey Savko <savko(a)tophouse.ru> wrote: > Versions x2goclient > Windows x2goclient 4.0.3.1 > Linux x2goclient: > $ apt-show-versions | grep x2goclient > x2goclient 4.0.3.2-0x2go1 newer than version in archive > nx-libs 3.5.0.29-0 > > $xdpyinfo > > name of display: :50 > version number: 11.0 > vendor string: The X.Org Foundation > vendor release number: 70000000 > X.Org version: 7.0.0 > maximum request size: 16777212 bytes > motion buffer size: 256 > bitmap unit, bit order, padding: 32, LSBFirst, 32 > image byte order: LSBFirst > number of supported pixmap formats: 7 > supported pixmap formats: > depth 1, bits_per_pixel 1, scanline_pad 32 > depth 4, bits_per_pixel 8, scanline_pad 32 > depth 8, bits_per_pixel 8, scanline_pad 32 > depth 15, bits_per_pixel 16, scanline_pad 32 > depth 16, bits_per_pixel 16, scanline_pad 32 > depth 24, bits_per_pixel 32, scanline_pad 32 > depth 32, bits_per_pixel 32, scanline_pad 32 > keycode range: minimum 8, maximum 255 > focus: window 0x1000018, revert to PointerRoot > number of extensions: 26 > BIG-REQUESTS > DAMAGE > DEC-XTRAP > DOUBLE-BUFFER > DPMS > Extended-Visual-Information > GLX > MIT-SHM > MIT-SUNDRY-NONSTANDARD > RANDR > RECORD > RENDER > SECURITY > SGI-GLX > SHAPE > SYNC > TOG-CUP > X-Resource > XC-APPGROUP > XC-MISC > XFree86-Bigfont > XINERAMA > XInputExtension > XKEYBOARD > XTEST > XVideo > default screen number: 0 > number of screens: 1 > > screen #0: > dimensions: 1920x1087 pixels (508x288 millimeters) > resolution: 96x96 dots per inch > depths (7): 24, 1, 4, 8, 15, 16, 32 > root window id: 0x59 > depth of root window: 24 planes > number of colormaps: minimum 1, maximum 1 > default colormap: 0x3f > default number of colormap cells: 256 > preallocated pixels: black 0, white 16777215 > options: backing-store YES, save-unders YES > largest cursor: 1920x1087 > current input event mask: 0xfac031 > KeyPressMask EnterWindowMask LeaveWindowMask > KeymapStateMask ExposureMask StructureNotifyMask > SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask > PropertyChangeMask ColormapChangeMask > number of visuals: 5 > default visual id: 0x3a > visual: > visual id: 0x3a > class: TrueColor > depth: 24 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > visual: > visual id: 0x3b > class: TrueColor > depth: 24 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > visual: > visual id: 0x3c > class: TrueColor > depth: 24 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > visual: > visual id: 0x3d > class: TrueColor > depth: 24 planes > available colormap entries: 256 per subfield > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > visual: > visual id: 0x3e > class: StaticColor > depth: 24 planes > available colormap entries: 256 > red, green, blue masks: 0xff0000, 0xff00, 0xff > significant bits in color specification: 8 bits > > > ----- Исходное сообщение ----- > От: "Ulrich Sibiller" <uli42(a)gmx.de> > Кому: "Sergey Savko" <savko(a)tophouse.ru> > Отправленные: Четверг, 12 Февраль 2015 г 22:54:35 > Тема: Re: 785 > > On Thu, Feb 12, 2015 at 4:02 PM, Sergey Savko <savko(a)tophouse.ru> wrote: >> I tested with lastest nx-libs. Bug is present. >> Last video with this bug: http://youtu.be/QTk1G1jLT-I > > Hmm, interesting. > > I suspect that your client is too old. What is it's version? What > nx-libs are included there? > > And please post the output of xdpyinfo in your session. > > Uli > > -- > Yours truly, > Sergey Savko. -- С уважением, Сергей Савко, начальник IT отдела. +7-931-361-04-02

2 2

Bug#785: 785
by Sergey Savko 12 Feb '15

12 Feb '15

I tested with lastest nx-libs. Bug is present. Last video with this bug: http://youtu.be/QTk1G1jLT-I -- Yours truly, Sergey Savko.

1 0

Bug#785: Bug#785: Bug#785: x2go clipboard bug
by Sergey Savko 11 Feb '15

11 Feb '15

To be precise it's not quite FreeNX. This patched FreeNX, called the RX from the company etersoft. Tomorrow I will try to update and test. -- Yours truly, Sergey Savko. ----- Исходное сообщение ----- От: "Ulrich Sibiller" <uli42(a)gmx.de> Кому: "Sergey Savko" <savko(a)tophouse.ru> Отправленные: Четверг, 12 Февраль 2015 г 0:34:29 Тема: Re: [X2Go-Dev] Bug#785: Bug#785: x2go clipboard bug So then try a newer x2go version. You should ensure that nx-libs is 3.5.0.28. Regarding FreeNX: I am pretty sure nx 3.4.0 did not have that clipboard problem I fixed in 3.5.0.28. Uli

1 0

Bug#785: x2go clipboard bug
by Sergey Savko 11 Feb '15

11 Feb '15

Package: x2goclient Version: 4.0.3.2 Severity: normal x2goclient doesnt work with clipboard properly. When you copy a file to clipboard and closed a source directory its just disapear from clipboard . It's with plain text also. When you copy to clipboard a part of a text from text document and then closed a text editor, the clipboard will be empty. -- Yours truly, Sergey Savko.

4 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev