X Server Security

download X Server Security

of 2

Transcript of X Server Security

  • 8/10/2019 X Server Security

    1/2

    10/14/2014 Critical Vulnerabilities

    https://security.fnal.gov/CriticalVuln/X-Servers.html

    Critical Vulnerability

    Open X Servers

    An open X server is one which accepts X client connections without restriction or authenticationof the client. Internet attackers are scanning networks for open X servers. In particular, scanningis done from a compromised system inside a site's perimeter, so blocking the X server ports atthe boundary is only a small help in preventing attacks on X.

    An X client can obtain an image of any open windows or the entire display, copies of allkeypress and/or mouse events sent to any windows, and can send synthetic events to windows. Ifan intruder has this access, he essentially can control all applications and sessions you haverunning. That leads to compromises of at least your account, and sometimes the entire system, onevery machine you are logged into.

    Secure X Servers

    You improve your security quite a bit by only allowing client connections from the systems youneed to use at any given moment. You can give your X server process a list of hosts from whichclient connenctions should be permitted. This is the next level of security above "none" and is

    barely acceptable. In this mode, your server is open to any user on any of the machines you haveenabled.

    Better security involves use of an authorization key, which is a string of bytes generated by the Xserver and stored in a private file on each machine where you want to run X clients. In the Unixworld, a command-line program xauthmanages this byte string. The string is sometimes referred

    to as a "magic cookie" or an "xauth key" X client programs obtain the string from the file whenthey open a connection to the X server. Because of the file protections, the key is only availableto processes running under your account (or as root). This reduces the risk exposure for yourdisplay.

    Even use of xauth keys leaves you vulnerable to sniffers on the network, because the X protocoltransfers the authorization key in the clear. The final increment of security comes fromcombining use of the authorization key with an encrypted network connection. The sshprogramcan create a side channel to carry your X connection from a remote client when you use sshtolog into that remote system. (Ssh creates the appearance of a separate X display on the remotesystem itself, with a separate authorization key, and presents itself to the real X server as a local

    client.)

    Securing your X server

    Unix & Linux

    Type xhost -to restrict access to certain client hosts. When the list of allowed clients is empty,access is then based on xauth keys. See the documentation for the xauthcommand for moreinformation.

  • 8/10/2019 X Server Security

    2/2

    10/14/2014 Critical Vulnerabilities

    https://security.fnal.gov/CriticalVuln/X-Servers.html

    WRQ Reflection

    Under the Settingsmenu, select Security. The Security modeMUST NOTbe set to"Unrestricted access". "User-based access" is preferred. Then you must ensure that your remote-session-starting commands either send your cookie (authorization key) to the remote host, or usessh to forward the X traffic over an encrypted tunnel. The middle choice, "Host-based access,"allows all users on any of your designated hosts to access your X display.

    When you choose user-based access, you have to send the authorization key to the remotesystem when you start a remote client. Including the following command in a session-startupdialog will do that:

    /usr/bin/X11/xauth add %IP#% %C%;

    With the semicolon in place as shown, you can simply put this before the xtermor whateverother command starts your remote X client. There's also a sample session definition fileyou canedit and save. (Be sure to change some-hostand yournameto fit the remote host's name and yourlogin name. (You may also have to change the paths to the xauth and xterm programs on theremote system.)

    There's a futher choice of what to do when clients not covered by the host- or user-based accesscontrol request a connection. If you set this to "prompt" you will get a dialog box every time thescanner checks your system. If you choose "prompt" you must deny the request to connect fromthe scanner when the dialog box appears or you will be found vulnerable and blocked again. Youcan only allow connections from nodes you recognize and trust. A setting of "refuse" isrecommended.

    Hummingbird Exceed

    For Exceed V8, you may want to bring it up to Version 8.0.0.7 or later, for reasons described onHummingbird's support pages.

    Run the xconfig utility (Start -> Programs -> Hummingbird Connectivity -> Exceed ->Xconfig)Go to the Security panelIn the Host Access Control Listsection, check the FilebuttonClick on the Editbutton to edit the xhost.txtfileAdd the names of any nodes which will run X client programs which you want to displaywindows on your Exceed X serverExit the editor and click OK

    For Exceed V8 and V9, edit %windir%\win.ini and add the lines

    [Exceed]

    AskUserToAddHost=0

    Restart Exceed

    (Thanks to Jim Smedinghoff for contributing the above.)

    [email protected]