An extensive set of X.org vulnerabilities
From: | Alan Coopersmith <alan.coopersmith-AT-oracle.com> | |
To: | xorg-announce-AT-lists.x.org | |
Subject: | [ANNOUNCE] X.Org Security Advisory: Protocol handling issues in X servers | |
Date: | Tue, 9 Dec 2014 08:00:35 -0800 | |
Message-ID: | <20141209160033.GA28951__43304.8671148301$1418141329$gmane$org@also.us.oracle.com> | |
Cc: | xorg-AT-lists.x.org, xorg-devel-AT-lists.x.org, Ilja Van Sprundel <ivansprundel-AT-ioactive.com> |
X.Org Security Advisory: Dec. 9, 2014 Protocol handling issues in X Window System servers =================================================== Description: ============ Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way the X server code base handles requests from X clients, and has worked with X.Org's security team to analyze, confirm, and fix these issues. Ilja's talk at the 30th Chaos Communication Congress (30C3) in Hamburg last year ("X Security: it's worse than it looks") gave a preview of these issues and discussed the general form of many of these, but did not disclose the exact details of them. The vulnerabilities could be exploited to cause the X server to access uninitialized memory or overwrite arbitrary memory in the X server process. This can cause a denial of service (e.g., an X server segmentation fault), or could be exploited to achieve arbitrary code execution. How critical these vulnerabilities are to any given installation depends on whether they run an X server with root privileges or reduced privileges; whether they run X servers exposed to network clients or limited to local connections; and whether or not they allow use of the affected protocol extensions, especially the GLX extension. The GLX extension to the X Window System allows an X client to send X protocol to the X server, to request that the X server perform OpenGL rendering on behalf of the X client. This is known as "GLX indirect rendering", as opposed to "GLX direct rendering" where the X client submits OpenGL rendering commands directly to the GPU, bypassing the X server and avoiding the X server code for GLX protocol handling. Most GLX indirect rendering implementations share some common ancestry, dating back to "Sample Implementation" code from Silicon Graphics, Inc (SGI), which SGI originally commercially licensed to other Unix workstation and graphics vendors, and later released as open source, so those vulnerabilities may affect other licensees of SGI's code base beyond those running code from the X.Org Foundation or the XFree86 Project. The vulnerabilities include: - denial of service due to unchecked malloc in client authentication CVE-2014-8091: In servers built with support for SUN-DES-1 (Secure RPC) authentication credentials, an unauthenticated client may be able to crash the X server by sending a connection request specifying values that cause malloc to fail, causing the authentication routines to attempt to write data to the returned NULL pointer. Since the request is limited to an unsigned 16-bit integer for the allocation size, it is unlikely to fail unless the server is severely memory constrained. Introduced in the initial revision of Secure RPC support in X11R5 (1991). - integer overflows calculating memory needs for requests These calls do not check that their calculations for how much memory is needed to handle the client's request have not overflowed, so can result in out of bounds reads or writes. These calls all occur only after a client has successfully authenticated itself. * CVE-2014-8092: X11 core protocol requests Affected functions: ProcPutImage(), GetHosts(), RegionSizeof(), REQUEST_FIXED_SIZE() Introduced in X11R1 (1987). * CVE-2014-8093: GLX extension Affected functions: __glXDisp_ReadPixels(), __glXDispSwap_ReadPixels(), __glXDisp_GetTexImage(), __glXDispSwap_GetTexImage(), GetSeparableFilter(), GetConvolutionFilter(), GetHistogram(), GetMinmax(), GetColorTable(), __glXGetAnswerBuffer(), __GLX_GET_ANSWER_BUFFER(), __glXMap1dReqSize(), __glXMap1fReqSize(), Map2Size(), __glXMap2dReqSize(), __glXMap2fReqSize(), __glXImageSize(), __glXSeparableFilter2DReqSize() Originally developed by SGI and licensed to multiple vendors prior to SGI open sourcing the code in 1999. Included in XFree86 releases starting in XFree86 4.0 (2000). Included in X.Org releases starting in X11R6.7 (2004). * CVE-2014-8094: DRI2 extension Affected functions: ProcDRI2GetBuffers() Introduced in xorg-server-1.7.0 (2009). - out of bounds access due to not validating length or offset values in requests These calls do not check that the lengths and/or indexes sent by the client are within the bounds specified by the caller or the bounds of the memory allocated to hold the request read from the client, so could read or write past the bounds of allocated memory while processing the request. These calls all occur only after a client has successfully authenticated itself. * CVE-2014-8095: XInput extension Affected functions: SProcXChangeDeviceControl(), ProcXChangeDeviceControl(), ProcXChangeFeedbackControl(), ProcXSendExtensionEvent(), SProcXIAllowEvents(), SProcXIChangeCursor(), ProcXIChangeHierarchy(), SProcXIGetClientPointer(), SProcXIGrabDevice(), SProcXIUngrabDevice(), ProcXIUngrabDevice(), SProcXIPassiveGrabDevice(), ProcXIPassiveGrabDevice(), SProcXIPassiveUngrabDevice(), ProcXIPassiveUngrabDevice(), SProcXListDeviceProperties(), SProcXDeleteDeviceProperty(), SProcXIListProperties(), SProcXIDeleteProperty(), SProcXIGetProperty(), SProcXIQueryDevice(), SProcXIQueryPointer(), SProcXISelectEvents(), SProcXISetClientPointer(), SProcXISetFocus(), SProcXIGetFocus(), SProcXIWarpPointer() Introduced in X11R4 (1989). * CVE-2014-8096: XC-MISC extension Affected functions: SProcXCMiscGetXIDList() Introduced in X11R6.0 (1994). * CVE-2014-8097: DBE extension Affected functions: ProcDbeSwapBuffers(), SProcDbeSwapBuffers() Introduced in X11R6.1 (1996). * CVE-2014-8098: GLX extension Affected functions: __glXDisp_Render(), __glXDisp_RenderLarge(), __glXDispSwap_VendorPrivate(), __glXDispSwap_VendorPrivateWithReply(), set_client_info(), __glXDispSwap_SetClientInfoARB(), DoSwapInterval(), DoGetProgramString(), DoGetString(), __glXDispSwap_RenderMode(), __glXDisp_GetCompressedTexImage(), __glXDispSwap_GetCompressedTexImage(), __glXDisp_FeedbackBuffer(), __glXDispSwap_FeedbackBuffer(), __glXDisp_SelectBuffer(), __glXDispSwap_SelectBuffer(), __glXDisp_Flush(), __glXDispSwap_Flush(), __glXDisp_Finish(), __glXDispSwap_Finish(), __glXDisp_ReadPixels(), __glXDispSwap_ReadPixels(), __glXDisp_GetTexImage(), __glXDispSwap_GetTexImage(), __glXDisp_GetPolygonStipple(), __glXDispSwap_GetPolygonStipple(), __glXDisp_GetSeparableFilter(), __glXDisp_GetSeparableFilterEXT(), __glXDisp_GetConvolutionFilter(), __glXDisp_GetConvolutionFilterEXT(), __glXDisp_GetHistogram(), __glXDisp_GetHistogramEXT(), __glXDisp_GetMinmax(), __glXDisp_GetMinmaxEXT(), __glXDisp_GetColorTable(), __glXDisp_GetColorTableSGI(), GetSeparableFilter(), GetConvolutionFilter(), GetHistogram(), GetMinmax(), GetColorTable() Originally developed by SGI and licensed to multiple vendors prior to SGI open sourcing the code in 1999. Included in XFree86 releases starting in XFree86 4.0 (2000). Included in X.Org releases starting in X11R6.7 (2004). * CVE-2014-8099: XVideo extension Affected functions: SProcXvQueryExtension(), SProcXvQueryAdaptors(), SProcXvQueryEncodings(), SProcXvGrabPort(), SProcXvUngrabPort(), SProcXvPutVideo(), SProcXvPutStill(), SProcXvGetVideo(), SProcXvGetStill(), SProcXvPutImage(), SProcXvShmPutImage(), SProcXvSelectVideoNotify(), SProcXvSelectPortNotify(), SProcXvStopVideo(), SProcXvSetPortAttribute(), SProcXvGetPortAttribute(), SProcXvQueryBestSize(), SProcXvQueryPortAttributes(), SProcXvQueryImageAttributes(), SProcXvListImageFormats() Introduced in XFree86 4.0.0 (2000). Included in X.Org releases starting in X11R6.7 (2004). * CVE-2014-8100: Render extension Affected functions: ProcRenderQueryVersion(), SProcRenderQueryVersion(), SProcRenderQueryPictFormats(), SProcRenderQueryPictIndexValues(), SProcRenderCreatePicture(), SProcRenderChangePicture(), SProcRenderSetPictureClipRectangles(), SProcRenderFreePicture(), SProcRenderComposite(), SProcRenderScale(), SProcRenderCreateGlyphSet(), SProcRenderReferenceGlyphSet(), SProcRenderFreeGlyphSet(), SProcRenderFreeGlyphs(), SProcRenderCompositeGlyphs() Introduced in XFree86 4.0.1 (2000). Included in X.Org releases starting in X11R6.7 (2004). * CVE-2014-8101: RandR extension Affected functions: SProcRRQueryVersion(), SProcRRGetScreenInfo(), SProcRRSelectInput(), SProcRRConfigureOutputProperty() Introduced in XFree86 4.2.0 (2002). Included in X.Org releases starting in X11R6.7 (2004). * CVE-2014-8102: XFixes extension Affected functions: SProcXFixesSelectSelectionInput() Introduced in X11R6.8.0 (2004). * CVE-2014-8103: DRI3 & Present extensions Affected functions: sproc_dri3_query_version(), sproc_dri3_open(), sproc_dri3_pixmap_from_buffer(), sproc_dri3_buffer_from_pixmap(), sproc_dri3_fence_from_fd(), sproc_dri3_fd_from_fence(), proc_present_query_capabilities(), sproc_present_query_version(), sproc_present_pixmap(), sproc_present_notify_msc(), sproc_present_select_input(), sproc_present_query_capabilities() Introduced in xorg-server-1.15.0 (2013). Affected Versions ================= X.Org believes all versions of the affected functions contain these flaws, dating back to their introduction. In the above listings, we've listed the earliest date of any of the affected functions in a given protocol or area - some functions listed may not have been introduced until later versions. Fixes ===== Fixes are available in git commits and patches which will be listed on http://www.x.org/wiki/Development/Security/Advisory-2014-... when this advisory is released. Fixes are also planned to be included in the xorg-server-1.17.0 and xorg-server-1.16.3 releases Other providers of Xserver or GLX implementations based on the same code base (the X Consortium or X.Org Foundation X sources, or the SGI GLX sources) will announce the availability of any fixes necessary for their implementations. Mitigation ========== While the fixes cover all the cases currently known to X.Org, these are not the first issues in this area and are unlikely to be the last. Users can reduce their exposure to issues similar to the ones in this advisory via these methods: * Configure the X server to prohibit X connections from the network by passing the "-nolisten tcp" command line option to the X server. Many OS distributions already set this option by default, and it will be set by default in the upstream X.Org release starting with Xorg 1.17. * Disable GLX indirect contexts. Some implementations have a configuration option for this. In Xorg 1.16 or newer, this can be achieved by setting the '-iglx' X server command line option. This option will be the default in Xorg 1.17 and later releases. Consult your operating system's documentation for details on setting X server command line options, as X servers are started by a variety of different methods on different platforms (startx, gdm, kdm, xdm, etc.). Thanks ====== X.Org thanks Ilja van Sprundel of IOActive for reporting these issues to our security team and assisting them in understanding them and evaluating our fixes, and the following X.Org contributors for developing and reviewing the fixes, tests, and advisory for these issues, and coordinating the X.Org response to them: Adam Jackson (Red Hat) Alan Coopersmith (Oracle) Andy Ritger (NVIDIA) Julien Cristau (Debian) Keith Packard (Intel) Michal Srb (SuSE) Peter Hutterer (Red Hat) Robert Morell (NVIDIA) -- -Alan Coopersmith- alan.coopersmith@oracle.com X.Org Security Response Team - xorg-security@lists.x.org _______________________________________________ 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: %(user_address)s
Posted Dec 9, 2014 20:53 UTC (Tue)
by sjj (guest, #2020)
[Link] (2 responses)
Posted Dec 9, 2014 21:38 UTC (Tue)
by drag (guest, #31333)
[Link] (1 responses)
There are a wide variety of situations were applications can fall back to indirect, including things like setting ld path or environmental variables.
Posted Dec 10, 2014 15:13 UTC (Wed)
by daniels (subscriber, #16193)
[Link]
Posted Dec 9, 2014 22:03 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Posted Dec 9, 2014 22:52 UTC (Tue)
by airlied (subscriber, #9104)
[Link]
They all share the core X protocol code and indirect GLX code.
Posted Dec 9, 2014 22:33 UTC (Tue)
by roskegg (subscriber, #105)
[Link] (35 responses)
When I was removed from Debian in 2006, it was just as I had gotten Keith Packard and Jim Getty's (the architects of X11 and X.org) to agree to a sit down with Theo de Raadt (leader of OpenBSD) to get talks started on how to fix the fundamental insecurity of X. Within hours I was escorted from the conference, and really wierd, trumped up charges were used to justify it.
So, the conference never happened. A forward plan to make X secure didn't happen. Instead, there was just a patchwork of some security fixes, but mostly new features and lots of code churn. Thanks, freedesktop.org.
Now that the Snowden stuff has come out, I wouldn't be surprised if that was related.
Or it could have been my talks with Intel to get them to release wireless driver specs... and continually getting blatantly lied to, and told things contradictory to what the Intel rep at the conference was telling me.
Anyhow, hey, once that all went down, I saw which way the wind was blowing. Linux has been corrupted by the NSA etc for a very, very long time.
Rio already exists; Rio and Plan9 are the way forward. They have bugs, but their design at least is sound. Let the porting begin...
Posted Dec 9, 2014 22:46 UTC (Tue)
by sjj (guest, #2020)
[Link] (22 responses)
Posted Dec 9, 2014 22:52 UTC (Tue)
by roskegg (subscriber, #105)
[Link] (21 responses)
Seriously, removing someone from a Free Software project because he asks not to eat pork at a conference; does that seem sane to you?
I'm alleging that Debian was/is just as corrupted by the NSA (and perhaps other agencies) as the IPSEC standards body was.
The corruption of Debians random number generator is another famous example.
Posted Dec 9, 2014 23:44 UTC (Tue)
by robert_s (subscriber, #42402)
[Link]
No, but you've got to realize that the fact it doesn't only makes your credibility as a source that much weaker. "Perhaps I'm not hearing the whole story here".
Posted Dec 10, 2014 0:46 UTC (Wed)
by ncm (guest, #165)
[Link] (6 responses)
It escapes me why Packard, Gettys, and de Raadt would need help meeting. Maybe they met anyhow.
Posted Dec 10, 2014 1:24 UTC (Wed)
by roskegg (subscriber, #105)
[Link] (5 responses)
Why would a meeting need to be arranged? The Open Source and Free Software movement have a lot of strong personalities, and often they clash. In a way, it is like the Balkans. Sometimes conflicts are perceived where they don't exist, so attempts to connect aren't made. Or the connections are being blocked by gatekeepers.
Or sometimes, parties are working on different projects, and aren't aware of each other, or aware that there is relevance and importance to a connection. Then a connector comes along.
A meeting between Gettys, Packard, Rob Pike, and the OpenBSD team to discuss a future X server that is secure would still be a good idea. But better if it had been done back in 2006. Or even earlier, when X.org was first forked.
In large swathes of the free software world, people like Richard Stallman, Eric Raymond, Daniel Bernstein and Theo de Raadt are cold-shouldered. It looks like there has been some thawing between djb and OpenBSD of late, which is a good sign.
Posted Dec 10, 2014 3:20 UTC (Wed)
by acoopersmith (subscriber, #72107)
[Link] (4 responses)
The biggest obstacle to getting these issues fixed is lack of developer time, not a lack of meetings between big name people with already full schedules.
Posted Dec 10, 2014 7:25 UTC (Wed)
by roskegg (subscriber, #105)
[Link] (3 responses)
When the OpenBSD guys started libressl, I heard the theme song was Twisted Sister's "We're not going to take it anymore".
When I looked into the IPSec standards, I felt the same way. I think many people felt that way, but were too embarassed to say so. Turned out the NSA had planted guys to munge up the standard.
There was something else that made me feel the same way. X11.
When X.org forked from XFree86, Keith Packard wrote a very nice piece about how easy it would be to write an X server from scratch, in about 60,000 (?) lines of code. When I looked at the XFree86 source, I had that same "We're not going to take it anymore" feeling the libressl team had. When I read what Keith wrote, I thought he was going to clean it up. Just like the libressl team are cleaning up openssl.
I understand the X sources getting crufty. They had to be portable back in the 80s, they had to deal with many operating systems and many different graphics cards and computer architectures and various bugs to work around. I get that. I really do. I'm not blaming Keith for imake. I'm glad it's gone. The modularity of the sources these days is a great improvement.
But the result is still something like OpenSSL. The birds are still coming home to roost. To me, todays bug disclosures say that Keith Packard never did rewrite the X server the way he talked about. The clean rewrite with all the old junk gone. Guess he was already too overworked, everyone screaming for support of the latest and greatest graphics cards. Linus invented git because "Linus doesn't scale". How about Keith and Jim? Does X.org have enough money to hire developers to work on fundamental things?
I look at the simplicity of Rio, and weep.
Posted Dec 10, 2014 7:48 UTC (Wed)
by drag (guest, #31333)
[Link] (1 responses)
X11 is designed for a different era. Blaming the NSA for X11 is like blaming them for NFSv3 having no security. It really doesn't make any sense and it's very rational.
It would be lovely if the NSA was to blame because then to fix software all we would have to do is get rid of the NSA. Unfortunately bad software design and implementations are much more insidious and systemic then that.
Posted Dec 10, 2014 7:53 UTC (Wed)
by roskegg (subscriber, #105)
[Link]
Posted Dec 10, 2014 8:41 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Dec 10, 2014 3:19 UTC (Wed)
by BenHutchings (subscriber, #37955)
[Link] (9 responses)
I can't say I agree with how you were treated at the formal dinner - however, the ejection from the project was justified based on your past behaviour and you should never have been allowed to attend the conference in the first place.
Posted Dec 10, 2014 8:27 UTC (Wed)
by roskegg (subscriber, #105)
[Link] (8 responses)
I was invited and encouraged to attend Debconf6 in Mexico. If you are going to eject someone for any reason, that isn't the way to do it.
As for not liking the way I was treated at Debconf, let's talk about your treatment. I had never met you before. The first time I saw you, you were scowling up into my face with clenched fists and a green shirt. I had just been assaulted at the Debian banquet. I wondered, who is this angry little Irishman, and why is he angry? I said hello in a friendly way. You grimaced even harder, then turned and walked away. Later on I asked and found out that the little green-clad man was you. Your disagreement with the way I was treated seems hypocritical when you act that way to a total stranger you've never met before.
Posted Dec 10, 2014 8:48 UTC (Wed)
by peter-b (guest, #66996)
[Link]
Perhaps you may make more headway in persuading people to sympathise with you if you revisit your approach?
Posted Dec 10, 2014 10:00 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (1 responses)
With just two sentences you just shot off both your feet as far as I'm concerned.
Posted Dec 10, 2014 19:28 UTC (Wed)
by rahvin (guest, #16953)
[Link]
I remember the first time he brought this up and I did a little reading on the subject because I was shocked at his allegations. I soon realized that IMO almost nothing he was claiming was true. That for the most part the reason this all happened is that he was a divisive twit that was tearing the community and project apart with entirely unrelated fringe political garbage. Which is not unlike his use of the misogynistic term SJW above. As a result of all the bridges he'd burned and salted he was tossed from the project, though in a poor fashion.
At least that's my reading of what went down for those that are curious he's left enough clues to google the whole thing and discover who and what he stands for.
Thank god we have freedom of association because I don't think I could spend 10 minutes in a room with this guy.
Posted Dec 10, 2014 13:27 UTC (Wed)
by BenHutchings (subscriber, #37955)
[Link] (1 responses)
You met me earlier than that. Also, I find it interesting that you choose to immediately identify people by nationality (wrongly in this case, but whatever).
Posted Dec 11, 2014 16:45 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Dec 10, 2014 21:14 UTC (Wed)
by da4089 (subscriber, #1195)
[Link]
Posted Dec 11, 2014 0:23 UTC (Thu)
by ncm (guest, #165)
[Link] (1 responses)
*BLOCKED*
Posted Dec 11, 2014 14:50 UTC (Thu)
by lsl (subscriber, #86508)
[Link]
I read that last bit as "favorite editor" first and already wanted to protest vehemently. After double-checking, though, there's nothing left to object to, so I can only agree 100 % with the above.
Posted Dec 10, 2014 12:52 UTC (Wed)
by lkundrak (subscriber, #43452)
[Link] (1 responses)
I thought that it's well understood that you were removed from the project basically because you were acting like an asshole? Just a few points of many:
> he responded by accusing the organisers of "kosher discrimination", and booking a "second rate hotel in a third world country" where the cooks are "not worth their salt".
and
> Ted brought along a foam rubber bat labelled with "clue", and hit a number of organisers and delegates with it.
Posted Jun 20, 2015 23:13 UTC (Sat)
by roskegg (subscriber, #105)
[Link]
I didn't claim anything negative about the hotel. In fact, one conference organizer secretly talked to hotel staff and made sure kosher food was available. I am very grateful to him. The conference organizers made claims to me, which made the resort sound like a third rate place. I repeated back to them, "this is what you are describing to me". It was the conference organizers who were misrepresenting the situation.
I didn't hit anyone with the foam club bat. The only time it saw use was near the end; one of the nicer conference organizers was trying to smooth things over, but he did it by repeatedly lying to my face. Not subtle lies, but blatant lies. I held up the bat and told him "You know I have to do this, right?" He nodded, and sat there while I tapped him on the shoulder with the foam. This happened after I'd already been assaulted and the process of eviction had started.
There are a lot of false claims going around about that conference; but I'm not the one making them.
Posted Dec 10, 2014 21:55 UTC (Wed)
by vonbrand (subscriber, #4458)
[Link]
Never forget Hanlon's razor...
Posted Dec 9, 2014 23:23 UTC (Tue)
by flussence (guest, #85566)
[Link] (3 responses)
Posted Dec 10, 2014 2:59 UTC (Wed)
by roskegg (subscriber, #105)
[Link] (2 responses)
Posted Dec 10, 2014 8:03 UTC (Wed)
by dgm (subscriber, #49227)
[Link] (1 responses)
Posted Dec 10, 2014 8:13 UTC (Wed)
by roskegg (subscriber, #105)
[Link]
Posted Dec 10, 2014 18:47 UTC (Wed)
by nwnk (guest, #52271)
[Link] (7 responses)
What an irrelevant pile of nonsense. The issues being patched here are all flaws in the realization, not the design. They are overwhelmingly in code that predates the fork from xfree86. And, at least from a quick look, the issues in code newer than the fork are primarily in code handling the client and server being opposite-endian of each other, meaning that to exploit them you would (in addition to defeating access control) either need to expose your X server to the network or be facing an attacker who can upload arbitrary code to the machine running the server.
On the other hand, since the fork, we've deleted literally tens of thousands of LOC implementing useless extensions, many of whose realizations had exactly the class of bugs being fixed here; and also about a hundred KLOC of duplicate software renderer, each a breeding ground for integer overflow bugs. That's whole sets of problems silently disappearing from your life. You're welcome.
We also merged an extension that _does_ let you write an actual locked-down policy to protect against X's fundamental security issues. But probably you don't want to hear about that, since that extension was written by the NSA, and being comfortable with that idea would require a more mature and nuanced view of reality.
Obviously I'm biased, since working on X has paid my bills for the last ten years or so. But from where I sit it looks like Xorg has proactively worked to make X more secure.
> Now that the Snowden stuff has come out, I wouldn't be surprised if that
Speaking as the author of the majority of the GLX fixes here (and most of the GLX bugfixes in X in the last five years or so), let's do the warrant canary thing:
At no point have I been contacted with warrants of any kind, or any similar instrument, or in any way, by governmental or non-governmental entities, about inclusion of any kind of malware or backdoor in the X server or any related code, or about the preservation of existing bugs to that effect. Neither am I aware of anyone else involved in X.org, freedesktop.org, or the Fedora Project having been so contacted. Neither am I aware of any such contact with any Red Hat employee.
Your accusations are unfounded and unhelpful. If I gave a toss about your opinion, I'd be offended.
Posted Dec 10, 2014 20:37 UTC (Wed)
by sjj (guest, #2020)
[Link] (6 responses)
Posted Dec 10, 2014 21:03 UTC (Wed)
by nwnk (guest, #52271)
[Link] (3 responses)
Sandboxing isn't necessarily better or worse. You get pretty solid isolation from the host X server, but that cuts both ways: XDND actions won't work, you don't get accelerated 3D (yet), etc. If all you want to do is isolate an app away from the containing X server's (elevated) privilege level, then sandboxing will do just fine. If you need actual MLS in one X display then XACE is the better mechanism.
But even there, X.org has actively enabled both the XACE and sandbox models. The selinux sandbox tool uses Xephyr, which wasn't a thing in XFree86, and we've taken patches to make Xephyr usable for the sandbox use case (initial window placement, resizable window, window title proxy, etc). If the assertion is that X.org has made no effort to improve X's security (as sir roskegg seemed to be claiming) then I really don't think the claim stands up to the evidence.
Posted Dec 10, 2014 21:25 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Dec 11, 2014 1:57 UTC (Thu)
by daniels (subscriber, #16193)
[Link] (1 responses)
Posted Dec 13, 2014 20:10 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Which already exists! (cf a bunch of earlier comments on LWN articles).
Which is why Wayland is X13.
Cheers
Posted Dec 11, 2014 17:05 UTC (Thu)
by dpquigl (guest, #52852)
[Link] (1 responses)
Posted Dec 11, 2014 19:39 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 10, 2014 0:43 UTC (Wed)
by josh (subscriber, #17465)
[Link] (39 responses)
Posted Dec 10, 2014 0:50 UTC (Wed)
by ncm (guest, #165)
[Link] (7 responses)
Posted Dec 10, 2014 6:58 UTC (Wed)
by mgraesslin (guest, #78959)
[Link] (4 responses)
On the other hand any other client connected to your X-Server is able to intercept all key events and it can know that you are typing in your browser. Furthermore it can place a window on top of the browser's location bar, which looks just like your browser's location bar.
Posted Dec 10, 2014 8:06 UTC (Wed)
by roskegg (subscriber, #105)
[Link]
Posted Dec 10, 2014 8:09 UTC (Wed)
by matthias (subscriber, #94967)
[Link] (2 responses)
Of course, the bigger problem is, that any client can intercept all events. This is a security nightmare. However, the server can do anything, the client can do. Why should attacker code executed in the server context have less privileges than an arbitrary client? All information available to X clients is also available to the server. That this information is usually not used by the server does not mean that introduced attacker code does not use it.
Posted Dec 10, 2014 8:51 UTC (Wed)
by drago01 (subscriber, #50715)
[Link] (1 responses)
Posted Dec 10, 2014 8:56 UTC (Wed)
by mgraesslin (guest, #78959)
[Link]
Posted Dec 10, 2014 8:11 UTC (Wed)
by wblew (subscriber, #39088)
[Link]
I found the wayland introduction talks that discussed X's shortcomings to be informative.
Posted Dec 12, 2014 7:40 UTC (Fri)
by thestinger (guest, #91827)
[Link]
This is prevented by grsecurity's ptrace feature or Yama's ptrace_scope (based on the latter) but they are not always enabled. They're fairly impractical on a machine used for software development (no strace -p, gdb -p, etc. without admin capabilities).
It would make sense to sandbox it (via seccomp, namespaces and chroot) but it's not going to accomplish much since as you pointed out it has access to all of the rendered frames for GUI apps + lots more.
Posted Dec 10, 2014 10:44 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (5 responses)
Posted Dec 10, 2014 20:38 UTC (Wed)
by sjj (guest, #2020)
[Link] (4 responses)
Posted Dec 10, 2014 21:13 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
Posted Dec 10, 2014 21:16 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
Posted Dec 10, 2014 21:23 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 11, 2014 14:38 UTC (Thu)
by lsl (subscriber, #86508)
[Link]
https://www.archlinux.org/news/xorg-server-116-is-now-ava...
Posted Dec 10, 2014 14:25 UTC (Wed)
by nye (subscriber, #51576)
[Link] (24 responses)
What exactly would that mitigate? If something has compromised the X server, what difference does it make who it's running as?
If it were running as nobody then it would at least be some minor mitigation, although the fact that your X clients are connected to a compromised X server pretty much means they're all effectively compromised. Running as the same user you're trying to protect doesn't gain you anything *at all*.
Posted Dec 10, 2014 15:11 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
Of course, elevating privileges once you 0wn user's X-server should not be that hard (just wait until user does 'sudo', for example) but it still requires non-trivial amount of effort from the malware creators.
Posted Dec 10, 2014 16:13 UTC (Wed)
by nye (subscriber, #51576)
[Link] (20 responses)
Really I'm just having a hard time seeing why a malware author would care. You don't need to be root to run a spam zombie, nor to have total access to all of the user's data. There are numerous ways of getting yourself restarted the next time the user logs on, and that's all it takes for a persistent compromise of the X server.
A rootkit is a useful weapon in a targetted attack, or against an opponent who's likely to be actively monitoring every process that runs, but the majority of malware doesn't bother using any kind of advanced methods to hide itself; it just assumes (almost always correctly) that nobody's going to be looking.
I guess if you don't have a rootkit then it's harder to keep control of the system long-term, but that's likely to be rather small consolation to the user who's just (for example) been blacklisted for sending 200000 spam mails, had their e-mail history and personal photos sent off to god-knows-where, and had their bank account drained.
If we really want to mitigate these sorts of problems, we need to be looking at something more like Qubes, or at least some form of application containerisation where access to any shared data is mediated via some supervisor.
For example, the only time my web browser needs access to any files that are outside of its own installation is when I'm saving or uploading files. The default downloads directory could be set to allow access, but every other file access outside its own container should require picking a file or directory via a picker *that is not controlled by the browser*. Currently there's already a file picker if I want to do that, so the user experience is not significantly changed, but if the file picker were a necessary part of the process rather than a bit of browser UI, then something that's compromised my browser can't access my personal files without explicitly asking me for them.
Unfortunately, as I understand it the design of X makes it impossible for clients to be prevented from monkeying around with each other. It does seem that the Wayland designers have been working with this in mind though, so I'm still hopeful that the situation will improve eventually, even if not in X.
Posted Dec 10, 2014 18:22 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (12 responses)
Exactly. Peoples' focus on protecting root, particularly on workstations or servers offering a shared service (a host running a set of REST services under an unprivileged user, for example), is at best quaint, and at worst a very foolish and dangerous waste of effort.
If the most an attacker can think to do with subverting my account is to root my machine, instead of, say, looting my bank accounts, I would be profoundly grateful.
Posted Dec 10, 2014 20:48 UTC (Wed)
by sjj (guest, #2020)
[Link] (7 responses)
You hit a bunch of developers and sysadmins with that and you've got access to some serious infrastructure.
Posted Dec 10, 2014 21:17 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (6 responses)
> curl https://install.meteor.com | /bin/sh
where the script there contains a 'sudo' (some go so far as to pipe to 'sudo sh'). Maybe sh should just refuse to listen to stdin that isn't a TTY without a script as an argument. Either way, this being your "install instructions" for *developers* to use your framework is 100% unacceptable.
Posted Dec 10, 2014 21:41 UTC (Wed)
by viro (subscriber, #7872)
[Link] (1 responses)
Posted Dec 10, 2014 21:44 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 10, 2014 21:59 UTC (Wed)
by sjj (guest, #2020)
[Link]
Posted Dec 10, 2014 23:16 UTC (Wed)
by tpo (subscriber, #25713)
[Link] (2 responses)
I do not understand, how that is much different from:
right-click somwhere->Save
$ tar xzvf some_stuff_downloaded_from_somewhere.tgz
Often enough I do these things in /tmp anyway, especally for stuff I'm updating. So it wouldn't survive the next reboot in case I'd need to analyze something after the fact.
What is the fundamental difference then to the "traditional" Unix way of installing fresh stuff?
I am aware that going the full length of verifying checksums and making educated plausibility checks based on that might be a bit better. However that is not the standard way of making sources available today and has been much less so in the olden days.
So I really still don't understand much.
Posted Dec 11, 2014 3:52 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
> where the script there contains a 'sudo' (some go so far as to pipe to 'sudo sh').
Hiding sudo behind a shell script you want be to blindly pipe to a shell is stupid no matter what.
I don't like the practice to begin with because at least with download/make/make install there is an inspection period (unless you find a code execution bug in tar or something). Personally, I configure all software to be installed into individual roots the select the roots depending on what is required. What I really need is a sandbox which blocks the tools from writing anywhere other than the source/build tree during the build and the build/install tree during install. I imagine SELinux could probably help here, but my knowledge of how to approach the problem there is close to nil right now.
Posted Dec 15, 2014 20:57 UTC (Mon)
by pjm (guest, #2080)
[Link]
Posted Dec 11, 2014 16:27 UTC (Thu)
by ortalo (guest, #4654)
[Link]
What you may like much less is that they are usually succeeding in elevating privileges and subsquently use them to protect their illegitimate access (from competiting attackers) and/or to attack other victims - leaving you as the apparent culprit. Admittedly they do not need to be root for the last part but it may help them relay their attacks longer and more easily.
Posted Dec 11, 2014 21:49 UTC (Thu)
by jwarnica (subscriber, #27492)
[Link] (2 responses)
If they get root, they can also install printer drivers.
La-de-dah.
Posted Dec 11, 2014 22:27 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Dec 12, 2014 5:51 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link]
If they get root, they can also install a rootkit. Which means that you can't even tell that they've infiltrated your PC. Which means that you don't know that they have your data, and that they can lurk in the background and collect new data as it's entered and/or use your PC as a base to infect other systems.
At least while the malware is limited to your unprivileged account you can see it with ordinary diagnostic tools and have a chance at removing it. If it gets root the only way to get back a clean PC is to wipe everything and restore from backup—and even the backups are suspect.
This is not to say that non-root malware is insignificant, just that there is good reason for giving the root account special consideration, even on single-user systems.
Posted Dec 10, 2014 18:44 UTC (Wed)
by lsl (subscriber, #86508)
[Link] (6 responses)
Ugh, please no. I don't want each application being its own isolated island. As a default mode of operation it's just wrong IMHO.
It's a model conceived for a world where apps written by someone else are considered hostile and bent on stealing your ad revenue or break your DRM or whatever. I don't consider it appropriate for the free software desktop, however. Here, programs SHOULD work together and take advantage of whatever else is installed on the system.
In other words: I don't think erecting security boundaries between processes belonging to the same user *by*default* is something desirable. It'd have huge costs to the malleability of the system and interop between programs. The tools should be there, though, to sandbox a particular set of processes. Just not as the default mode of operation.
Posted Dec 10, 2014 19:58 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (2 responses)
Posted Dec 10, 2014 20:02 UTC (Wed)
by dlang (guest, #313)
[Link] (1 responses)
Users need to be able to use the same data files with multiple apps. Granting access where it's needed and wanted without granting access where it's not (or where it's dangerous) is not a solvable problem.
Posted Dec 10, 2014 20:54 UTC (Wed)
by sjj (guest, #2020)
[Link]
I think I'm getting to the point where Qubes is very very interesting. It gives you isolation and configurability, granted at the cost of some convenience and hardware (vt-d and enough memory).
Posted Dec 13, 2014 3:31 UTC (Sat)
by gmatht (guest, #58961)
[Link] (2 responses)
The user should not even know that the app is contained; for "normal" apps this is a solved problem. If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file. Likewise clicking "paste" or "Control-V" gives the application the right to read the clipboard. There was even an attempt to retrofit this using LD_PRELOAD so that existing GTK software could be so constrained without so much as a recompile. I understand one reason this didn't take off is that due to X's security weaknesses it didn't add much extra security without nested X servers. There have been cases of software being discretely tampered with. But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.
Posted Dec 13, 2014 5:26 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (1 responses)
And there's the problem. Not everybody has the same notion of a "normal" app. I just don't see how you would do it without either losing tons of flexibility or writing tons of complicated policy.
> If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file.
Let's leave aside the fact that there's nothing like a standard file open dialog on my system and imagine a system where somehting like that exists and is chosen by the admin or on a per-user-session basis. This magic file picker needs to be appropriate for all apps that are going to run inside that session. I just don't see this happen. What about computed paths or those obtained from the user in some other way? All this would be severely restricting the kind of app you can write (or require much policy-writing effort upfront).
It might work on Android where you have a pretty restricted app model (and app are mostly trivial and don't work much with local files anyway). Or even for big applications that don't interact much with the system. But for the general case on a general-purpose computer?
How would you contain something like Emacs without severely neutering its usefulness?
> But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.
Yes, of course. That's a problem, I agree. I just think the solution is going to be a little harder.
Posted Dec 13, 2014 15:30 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
>And there's the problem. Not everybody has the same notion of a "normal" app. I just don't see how you would do it without either losing tons of flexibility or writing tons of complicated policy.
Just because it can't work transparently for every possible program doesn't mean that it's not a good model to start from, a target to aim for, or that it won't work for the vast majority of desktop software.
>> If the application opens a file using the standard (and trusted) file open dialog, the application gets rights to that file.
Well, that's kind of your problem, you can't always take advantage of the work and standards that others make if you march to the beat of your own drummer, that goes for the app developers too.
> This magic file picker needs to be appropriate for all apps that are going to run inside that session. I just don't see this happen.
The vast majority of apps use a toolkit which provides a comprehensive, flexible, file picker widget. What you really need is negotiation and agreement from the top two or three toolkit developers to add support for file pickers over IPC with a standard policy hook, if this doesn't already exist.
Of course that won't cover all programs but you can hopefully cover the most exposed targets and provide guidance for the rest to come along on their own time. I think you still get significant benefit if you can containerize the top 80 out of 100 of the most used desktop applications, even if there are 10,000 other apps which aren't covered.
> It might work on Android
Yes, you see a bunch of work on this on more modern platforms. The new-type systems like Android , iOS and ChromeOS may replace traditional desktop systems like Windows, MacOS and Linux anyway except maybe for certain kinds of content creation and software development work.
> How would you contain something like Emacs without severely neutering its usefulness?
To contain an app like that there would be constraints which you might consider neutering because while you would be able to do the things you want to do you probably won't be able to negotiate on the _way_ you do them. An example of a constrained file access model might have ~/Documents/Emacs "owned" by emacs and this (along with ~/.config/Emacs and ~/.local/Emacs, maybe a few other settings files) are the only places where it can do unconstrained read/write, every other file access is either read-only or uses an IPC service which validates the request. That would would be a constraint on where you put your source code projects, mail spool, etc. that you expect to be editing, probably necessitating remote source control to get files in and out of the container. You might also make your app require its own private repository of tools rather than having shared tools as part of your OS, so it gets its own /usr with docs and compilers and whatever.
> > But even if there aren't any intentional holes, if your application has one little buffer overflow and parses one slightly odd attachment then suddenly your friendly F/OSS software becomes rather hostile.
> Yes, of course. That's a problem, I agree. I just think the solution is going to be a little harder.
Anyway this kind of containerization is very possible but there are tradeoffs. Concentrating on the programs which are most likely to be exposed, like web browsers, anything that might be spawned as a dependency of viewing an attachment, anything that talks directly over the network, is going to provide the most bang for the buck.
Also comprehensive political and legal reform on how the internet is regulated to try and reduce the base level of hostility in the environment would be a good parallel project to technical security measures. 8-)
Posted Dec 10, 2014 21:46 UTC (Wed)
by josh (subscriber, #17465)
[Link]
Posted Dec 19, 2014 12:29 UTC (Fri)
by Rudd-O (guest, #61155)
[Link]
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
Did Xgl suffer from this?
http://cgit.freedesktop.org/xorg/xserver/tree/hw/xgl?id=c...
Did Xgl suffer from this?
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
You mean, a server that doesn't even do OpenGL and is horribly unsuitable for anything remotely modern?
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
You may not like my sincerely held views. I know faith-bashing is popular in your country. But calling me a troll doesn't make it so.
As for not liking the way I was treated at Debconf, let's talk about your treatment. I had never met you before. The first time I saw you, you were scowling up into my face with clenched fists and a green shirt. I had just been assaulted at the Debian banquet. I wondered, who is this angry little Irishman, and why is he angry?
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
> patchwork of some security fixes, but mostly new features and lots of
> code churn. Thanks, freedesktop.org.
> was related.
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
Wol
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
>
> $ curl https://install.meteor.com | /bin/sh
$ cd some_stuff_downloaded_from_somewhere/
$ make
$ (maybe: sudo) make install
*t
An extensive set of X.org vulnerabilities
vulnerabilities during installation & execution
An extensive set of X.org vulnerabilities
Attackers will only loot your bank account when everything *else* is over.
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities
Containing software without annoying users
Containing software without annoying users
Containing software without annoying users
> Let's leave aside the fact that there's nothing like a standard file open dialog on my system
An extensive set of X.org vulnerabilities
An extensive set of X.org vulnerabilities