|
|
Subscribe / Log in / New account

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


to post comments

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 20:53 UTC (Tue) by sjj (guest, #2020) [Link] (2 responses)

Any examples of apps using indirect GLX?

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 21:38 UTC (Tue) by drag (guest, #31333) [Link] (1 responses)

Any application that uses direct GLX can potentially use indirect GLX. Plus we have AIGLX, which provides opengl acceleration through the server rather then direct rendering.

There are a wide variety of situations were applications can fall back to indirect, including things like setting ld path or environmental variables.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 15:13 UTC (Wed) by daniels (subscriber, #16193) [Link]

Not all of them - indirect GLX doesn't even do GL 2.0, so you'd be struggling to find anything better than ppracer, really.

Did Xgl suffer from this?

Posted Dec 9, 2014 22:03 UTC (Tue) by HelloWorld (guest, #56129) [Link] (1 responses)

I don't understand the source well enough to tell, but maybe somebody else can:
http://cgit.freedesktop.org/xorg/xserver/tree/hw/xgl?id=c...

Did Xgl suffer from this?

Posted Dec 9, 2014 22:52 UTC (Tue) by airlied (subscriber, #9104) [Link]

yes and Xwayland does as well.

They all share the core X protocol code and indirect GLX code.

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 22:33 UTC (Tue) by roskegg (subscriber, #105) [Link] (35 responses)

This has always been the shoe waiting to drop.

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...

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 22:46 UTC (Tue) by sjj (guest, #2020) [Link] (22 responses)

You're alleging Keith Packard, Jim Gettys, and *Debian* are in collusion with NSA? Sounds like one of those extraordinary claims that require extraordinary evidence. If that's not what you're saying, my apologies for misinterpreting. Please clarify.

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 22:52 UTC (Tue) by roskegg (subscriber, #105) [Link] (21 responses)

Jim Getty's and Keith Packard agreed to the sit-down with Theo de Raadt. They had nothing to do with my removal from Debian, as far as I can tell.

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.

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 23:44 UTC (Tue) by robert_s (subscriber, #42402) [Link]

"Seriously, removing someone from a Free Software project because he asks not to eat pork at a conference; does that seem sane to you?"

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".

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 0:46 UTC (Wed) by ncm (guest, #165) [Link] (6 responses)

Seeding corruption would be an unnecessary expense when incompetence is on offer in so many places for no charge.

It escapes me why Packard, Gettys, and de Raadt would need help meeting. Maybe they met anyhow.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 1:24 UTC (Wed) by roskegg (subscriber, #105) [Link] (5 responses)

The level of competence in Debian was fairly high, although seems to be dropping a bit over time. Systemd takes Debian outside its core competence, which is (or was) sysadmin.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 3:20 UTC (Wed) by acoopersmith (subscriber, #72107) [Link] (4 responses)

The maintainer of the X11 port to OpenBSD has also served as the co-lead of X.Org's security team the past few years, and was a member of the X.Org Board of Directors as well. OpenBSD is already as involved as their time and desire allows them to be.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 7:25 UTC (Wed) by roskegg (subscriber, #105) [Link] (3 responses)

Alan, thanks for that update. The events I describe happened 8 years ago. I'm glad to see the progress that has been made, and appreciate Matthieu Herrb's work.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 7:48 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

> There was something else that made me feel the same way. X11.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 7:53 UTC (Wed) by roskegg (subscriber, #105) [Link]

No one blamed the NSA for X11. Or X10. Go back and re-read. Situations can get fubared in many different ways, but fubar situations are all the same, in many important ways.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> I look at the simplicity of Rio, and weep.
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

Posted Dec 10, 2014 3:19 UTC (Wed) by BenHutchings (subscriber, #37955) [Link] (9 responses)

You are a troll and you were ejected from DebConf 6 and the Debian project because of that.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:27 UTC (Wed) by roskegg (subscriber, #105) [Link] (8 responses)

Your SJW disqualification tactics don't work anymore, Ben. 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.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:48 UTC (Wed) by peter-b (guest, #66996) [Link]

I don't know if you intend it that way, but unfortunately you're coming across as a really unpleasant person in the way that you write your posts. This isn't helping you very much.

Perhaps you may make more headway in persuading people to sympathise with you if you revisit your approach?

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 10:00 UTC (Wed) by rodgerd (guest, #58896) [Link] (1 responses)

> Your SJW disqualification tactics don't work anymore, Ben. 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.

With just two sentences you just shot off both your feet as far as I'm concerned.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 19:28 UTC (Wed) by rahvin (guest, #16953) [Link]

Blew off both legs and cut his own throat.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 13:27 UTC (Wed) by BenHutchings (subscriber, #37955) [Link] (1 responses)

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.

So these are all sincere?

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?

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).

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 16:45 UTC (Thu) by nix (subscriber, #2304) [Link]

Quite possibly they are sincere positions. However, sincerely being a sexist conspiracy theorist loon still doesn't reflect well on him.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:14 UTC (Wed) by da4089 (subscriber, #1195) [Link]

Let's see: My Account, Edit Filtering, roskegg, Ok. Ahhh, that's better.

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 0:23 UTC (Thu) by ncm (guest, #165) [Link] (1 responses)

Wow, sizeist, too. Jonathan, worthiness correlates no better with national origin or physical stature than it does with sex, skin color, dental configuration, hair details, shoe size, personal wealth, or favorite color.

*BLOCKED*

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 14:50 UTC (Thu) by lsl (subscriber, #86508) [Link]

> Wow, sizeist, too. Jonathan, worthiness correlates no better with national origin or physical stature than it does with sex, skin color, dental configuration, hair details, shoe size, personal wealth, or favorite color.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 12:52 UTC (Wed) by lkundrak (subscriber, #43452) [Link] (1 responses)

Please stop this.

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.

An extensive set of X.org vulnerabilities

Posted Jun 20, 2015 23:13 UTC (Sat) by roskegg (subscriber, #105) [Link]

Both those statements are flat out lies.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:55 UTC (Wed) by vonbrand (subscriber, #4458) [Link]

Never forget Hanlon's razor...

An extensive set of X.org vulnerabilities

Posted Dec 9, 2014 23:23 UTC (Tue) by flussence (guest, #85566) [Link] (3 responses)

A fascinating story, you had me going there until it turned into a sales pitch.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 2:59 UTC (Wed) by roskegg (subscriber, #105) [Link] (2 responses)

Weren't you the Debian Project Leader at the time this all happened?

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:03 UTC (Wed) by dgm (subscriber, #49227) [Link] (1 responses)

maybe you're confusing him with Anthony Towns.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:13 UTC (Wed) by roskegg (subscriber, #105) [Link]

How many flussence are out there that aren't named Anthony Towns?

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 18:47 UTC (Wed) by nwnk (guest, #52271) [Link] (7 responses)

> 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.

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
> was related.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 20:37 UTC (Wed) by sjj (guest, #2020) [Link] (6 responses)

You mean XSELinux? Is it used by anybody? According to SElinux wiki, even Fedora doesn't enable it. Instead you're supposed to use manual sandboxes.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:03 UTC (Wed) by nwnk (guest, #52271) [Link] (3 responses)

That is what I mean, though it's spelled XACE now. The extension isn't enabled by default, but it's there if you want it. Admittedly I don't know where one would go to acquire a reasonable "default" policy for it; if someone wanted to write one, I'd happily ship it.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:25 UTC (Wed) by raven667 (subscriber, #5198) [Link] (2 responses)

If anything, the rewrite to fix fundamental security problems with X11 is called Wayland (X13 in all but name)

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 1:57 UTC (Thu) by daniels (subscriber, #16193) [Link] (1 responses)

Kinda-sorta. If Wayland really was a newer version of X, it'd be called X12. It makes a number of radically different design decisions (ones which I'd argue are improvements, mind), so it'd be unfair to call it X12. Much like calling Linux, Minix 2.

An extensive set of X.org vulnerabilities

Posted Dec 13, 2014 20:10 UTC (Sat) by Wol (subscriber, #4433) [Link]

> Kinda-sorta. If Wayland really was a newer version of X, it'd be called X12.

Which already exists! (cf a bunch of earlier comments on LWN articles).

Which is why Wayland is X13.

Cheers
Wol

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 17:05 UTC (Thu) by dpquigl (guest, #52852) [Link] (1 responses)

XACE and the SELinux module are there to solve a different purpose than simple application sandboxing. There are people who use it and they use it to implement systems similar to older Compartmented Mode Workstations (CMWs). I use to work with the XACE guy and the demos he had were for information flow control. He had a demo that used the MLS components of an SELinux context to prevent copy and paste between editors of different levels. The problem and reason why we don't use it in Fedora is that X11 and the applications and frameworks that run on top of it aren't built to handle this extra security. They make many assumptions about access to information via the X protocol and die horribly in a fire if they don't get access to it. Many of the applications tested would just crash and exit because they weren't written to assume certain calls can fail which was not the case with the new access control framework.

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 19:39 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

It would be interesting to have a tool which I could shim in between the real X server and a client that would implement XACE and/or XSELinux so that I can test applications with the restrictions. ISTR an application which would do so for logging at least.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 0:43 UTC (Wed) by josh (subscriber, #17465) [Link] (39 responses)

The best mitigation, by far, would be to run X as an unprivileged user, ideally the user whose session it supports. X hasn't needed root for a long time.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 0:50 UTC (Wed) by ncm (guest, #165) [Link] (7 responses)

Why does X need access to my files? Let it run as "nobody". That said, it has access to my passwords as I type them in, so taking away root doesn't help much.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 6:58 UTC (Wed) by mgraesslin (guest, #78959) [Link] (4 responses)

Luckily X doesn't know that you enter the password. All it sees is that it has to deliver key events to a window. It doesn't semantically know what the window is and where the key strokes are going. It might know it's a browser window, but it cannot know whether you enter an URL or your bank account pin. Sometimes being stupid is a feature ;-)

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:06 UTC (Wed) by roskegg (subscriber, #105) [Link]

Bingo. X.org is a "second system". I believe Rio is the third system, but it never fledged its wings.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:09 UTC (Wed) by matthias (subscriber, #94967) [Link] (2 responses)

Would you mind, if I would attach a key logger to your keyboard? The key logger does not know when you enter a password. Still, the passwords are captured and any human, who gets to see this series of keystrokes can identify them. Even automatic retrieval should give quite good results. Passwords usually look quite different compared to URLs.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:51 UTC (Wed) by drago01 (subscriber, #50715) [Link] (1 responses)

The xserver also has access to the *output* ... it could capture images of the screen in addition to the keystrokes.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:56 UTC (Wed) by mgraesslin (guest, #78959) [Link]

Also each client connected to the same X server can capture the output of any other window. That's what a compositor does.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 8:11 UTC (Wed) by wblew (subscriber, #39088) [Link]

The X server is vulnerable, by design, to other local clients. That's a basic fact.

I found the wayland introduction talks that discussed X's shortcomings to be informative.

An extensive set of X.org vulnerabilities

Posted Dec 12, 2014 7:40 UTC (Fri) by thestinger (guest, #91827) [Link]

Running stuff as nobody is not a good approach to securing a system. For example, one process running as nobody can ptrace (i.e. debug, just like gdb) another so it falls apart as soon as it's used for more than one process. It also impacts files, temporary files and some forms of IPC - not just the ability to ptrace.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 10:44 UTC (Wed) by HelloWorld (guest, #56129) [Link] (5 responses)

It can be done nowadays thanks to logind.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 20:38 UTC (Wed) by sjj (guest, #2020) [Link] (4 responses)

Got links?

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:13 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

I haven't set it up for my 'startx' workflow yet, but Fedora 21 shouldn't have a root X server if you're using a typical DE:

https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:16 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

That's scheduled for Fedora 22. Not Fedora 21.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:23 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Oh, indeed. I missed the detail section and saw "Install Fedora 21" in the "How To Test" section. Probably needs updating then :) .

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 14:38 UTC (Thu) by lsl (subscriber, #86508) [Link]

It pretty much works out-of-the-box on Arch Linux. That is, as long as you're starting X via startx. Don't know what's the state with the various display managers.

https://www.archlinux.org/news/xorg-server-116-is-now-ava...

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 14:25 UTC (Wed) by nye (subscriber, #51576) [Link] (24 responses)

>The best mitigation, by far, would be to run X as an unprivileged user, ideally the user whose session it supports

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*.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 15:11 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (22 responses)

Well, trojan writers' options are much more limited if you only have to run as an unprivileged user. You can't really rootkit a system without being root.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 16:13 UTC (Wed) by nye (subscriber, #51576) [Link] (20 responses)

>You can't really rootkit a system without being root.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 18:22 UTC (Wed) by rodgerd (guest, #58896) [Link] (12 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.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 20:48 UTC (Wed) by sjj (guest, #2020) [Link] (7 responses)

I'm just waiting for an attack that will exfiltrate $HOME/{.ssh/*|.gnupg/|.*history|.aws/*|.boto} etc using a popular Rubygem or Github-hosted script (just as an example).

You hit a bunch of developers and sysadmins with that and you've got access to some serious infrastructure.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:17 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (6 responses)

What we really need to stop is shit like this:

> 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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:41 UTC (Wed) by viro (subscriber, #7872) [Link] (1 responses)

Congratulations, you've just broken !!sh<enter> in vi. I.e. something I'm using all the time - shell commands composed in editor, piped to shell and replaced with their output. And I suspect that emacs folks also won't thank you for that. It's a fairly common workflow.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:44 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Well, I did say "maybe". Yes, that certainly seems useful (and isn't something I do often, so hadn't come to mind).

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:59 UTC (Wed) by sjj (guest, #2020) [Link]

Yes, this is an execrable anti-pattern. RVM does it too and they only just last month (!) added release signing...

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 23:16 UTC (Wed) by tpo (subscriber, #25713) [Link] (2 responses)

> What we really need to stop is shit like this:
>
> $ curl https://install.meteor.com | /bin/sh

I do not understand, how that is much different from:

right-click somwhere->Save

$ tar xzvf some_stuff_downloaded_from_somewhere.tgz
$ cd some_stuff_downloaded_from_somewhere/
$ make
$ (maybe: sudo) make install

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.
*t

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 3:52 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

You missed the rest of the sentence:

> 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.

vulnerabilities during installation & execution

Posted Dec 15, 2014 20:57 UTC (Mon) by pjm (guest, #2080) [Link]

I think tpo's point wasn't that there's nothing wrong for a user to do "curl | sh", but rather to remind readers that the "make && (maybe sudo) make install" part (or even the "run resulting executable" part) isn't so very different: that your advice of using containers, or at least reading the source, applies in both cases.

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 16:27 UTC (Thu) by ortalo (guest, #4654) [Link]

Whatever your gratitude, IMHO, that may be what they try to do first.

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.
Attackers will only loot your bank account when everything *else* is over.

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 21:49 UTC (Thu) by jwarnica (subscriber, #27492) [Link] (2 responses)

If they get my account, they get all the data I care about. And mine bitcoins, spam whomever. Whatever.

If they get root, they can also install printer drivers.

La-de-dah.

An extensive set of X.org vulnerabilities

Posted Dec 11, 2014 22:27 UTC (Thu) by josh (subscriber, #17465) [Link]

I agree with you; once an attacker has a local account, even an unprivileged one, you've lost. However, unless you have TCP turned on (which you shouldn't), all of these X vulnerabilities only provide local exploits, not remote exploits. And running X as the same user running the apps connecting to it means those local exploits don't actually gain any privilege.

An extensive set of X.org vulnerabilities

Posted Dec 12, 2014 5:51 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> If they get root, they can also install printer drivers.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 18:44 UTC (Wed) by lsl (subscriber, #86508) [Link] (6 responses)

> or at least some form of application containerisation where access to any shared data is mediated via some supervisor.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 19:58 UTC (Wed) by HelloWorld (guest, #56129) [Link] (2 responses)

No, you're utterly wrong. Compartmentalizing things is the only way to ever get a reasonably secure system. And this has nothing at all to do with whether the programs are open source or not.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 20:02 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

a secure system that doesn't do what the users need to do is worthless.

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.

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 20:54 UTC (Wed) by sjj (guest, #2020) [Link]

You're both right, I think.

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).

Containing software without annoying users

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.

Containing software without annoying users

Posted Dec 13, 2014 5:26 UTC (Sat) by lsl (subscriber, #86508) [Link] (1 responses)

> The user should not even know that the app is contained; for "normal" apps this is a solved problem.

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.

Containing software without annoying users

Posted Dec 13, 2014 15:30 UTC (Sat) by raven667 (subscriber, #5198) [Link]

>> The user should not even know that the app is contained; for "normal" apps this is a solved problem.

>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.
> Let's leave aside the fact that there's nothing like a standard file open dialog on my system

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-)

obligatory XKCD:

Posted Dec 10, 2014 19:46 UTC (Wed) by HelloWorld (guest, #56129) [Link]

An extensive set of X.org vulnerabilities

Posted Dec 10, 2014 21:46 UTC (Wed) by josh (subscriber, #17465) [Link]

All of these X server compromises require that you have a connection to the X server. Assuming the server doesn't listen via TCP, and it runs as a user with access only for that user, then only that user can compromise it, and they'd only get the same permissions they already have. It wouldn't be a privilege *escalation*, the way a user exploit of an X server running as root would be.

An extensive set of X.org vulnerabilities

Posted Dec 19, 2014 12:29 UTC (Fri) by Rudd-O (guest, #61155) [Link]

I am so profoundly happy that I made the call to use Qubes OS exclusively.


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds