In addition to remote terminal access, slick or otherwise , you may also be interested in what GUI access methods may be available. This section takes a brief look at VNC, Timbuktu, and Apple Remote Desktop.
AT&T Laboratories Cambridge has developed a platform-independent remote display protocol called VNC, Virtual Network Computing. The display protocol enables you to display a desktop running on a remote host on your local machine. A VNC server runs on the remote host, and a VNC client runs on the local machine. For more information on VNC, visit http://www.realvnc.com/ and http://www.uk.research.att.com/vnc/. The AT&T VNC team now distributes the latest version of its software at the RealVNC site as source and for some selected platforms, but the AT&T site still has older versions and versions for platforms not available at the RealVNC site. A VNC server and client are available directly from AT&T for traditional Mac OS. Additionally there are links to ports to Mac OS X, and source code is available. For Mac OS X a number of VNC viewers are available, and a VNC server for X11 has been ported to OS X. Additionally, a couple servers that display the aqua interface are available. Regularly check AT&T's site at http://www.uk.research.att.com/vnc/contribs.html, and also http:// sourceforge .net/, and http://www. versiontracker .com/ for information on such projects.
The primary vulnerability with the VNC protocol is that it is a cleartext protocol. A password is required when a VNC viewer connects to a VNC server, and this password is encrypted, but the following graphical data is not. It is recommended that if you are going to use it, use it over SSH.
In addition to the flaw in the protocol itself, a few vulnerabilities in VNC software have been discovered so far. They include the following:
Weak Authentication Process (VU# 303080, BugTraq ID 2275)
VNC's authentication process can allow an intruder eavesdropping on the network traffic to gain access to a desktop and its system. The weakness is in the challenge and response system between the server and client. The recommended solution is to tunnel VNC connections over SSH.
WinVNC Server Buffer Overflow (CAN-2001-0168, VU# 598581, BugTraq ID 2306)
A vulnerability exists in WinVNC server's handling of HTTP requests that can result in an attacker's being able to execute arbitrary code with the privilege of the WinVNC server process. The vulnerability exists in WinVNC Server 3.3.3r7 and earlier. Upgrade to the latest version or apply a patch that is available on CERT's site.
WinVNC Weak Registry Permissions Permissions (CVE-2000-1164, VU# 197477, BugTraq ID 1961)
A default WinVNC installation creates a Registry key that contains connection password, IP address, and query restrictions with full access granted to Administrator and System accounts. An attacker could modify the registry to allow unauthenticated access to the service. The recommended solution is to remove the Everybody and Standard Users permissions from the registry key.
The following sections list some of the Mac OS X ports that are currently available:
Xvnc . Information on Xvnc , a VNC server for serving X11 applications from MacOS X, is available at http://www.cdc.noaa.gov/~jsw/macosx_xvnc/. Ultimately, versions of Xvnc for Mac OS X are distributed via the fink system, which is available at http://fink.sourceforge.net/.
To install this port of the server, first install fink . Then install the xfree86-base package. Finally, install either the vnc or the tightvnc package. The tightvnc package is a port of TightVNC, a version of VNC that is optimized for slower network connections, among other things. For more information, see http://www.tightvnc.com/.
OSXVnc . OSXVnc is an Aqua VNC server, available from http://prdownloads.sourceforge.net/osxvnc/. For information on OSXVnc, check Redstone Software's site at http://www.redstonesoftware.com/osxvnc/.
Share My Desktop . Share My Desktop is another Aqua VNC server, available from http://www.bombich.com/software/smd.html.
Various VNC viewers are available for Mac OS X. Some of the viewers are also available for older versions of Mac OS. Among them are
Chicken of the VNC, available from http://www.geekspiff.com/software/cotvnc. This is a Mac OS X application.
VNCDimension, available from http://www.mdimension.com/cgi-bin/WebObjects/mDimension.woa. This is a Mac OS X application.
VNCThing, available from http://webthing.net/vncthing/. This runs on Mac OS 8.1 and later.
VNCViewer, available from http://homepage.mac.com/kedoin/VNC/VNCViewer/. This is a Mac OS X application.
VNCViewer, available from http://www.geocities.com/tim_senecal/vnc.html. This site has a carbon version, a noncarbon version, and even one for 68k Macs.
After VNC is installed, you start Xvnc , the server, on the remote host whose desktop you want to access, and you run a VNC viewer, the client, on the local machine. Typically, Xvnc is started by vncserver . If you are using Xvnc for Mac OS X, try vncserver with the “depth and “geometry options to set bit depth and screen resolution suitable to your monitor.
As you may recall from the section on VNC vulnerabilities, it is recommended that VNC be run over SSH. When you log in to the remote host and run vncserver , it will return a display number. The VNC protocol uses port 59XX , where XX is the display number. Here is a sample of starting Xvnc :
Rosalyn joray 66 > vncserver New 'X' desktop is Rosalyn:1 Starting applications specified in /net/rosalyn/home2/joray/.vnc/xstartup Log file is /net/rosalyn/home2/joray/.vnc/Rosalyn:1.log
The first time you run vncserver , you will be asked to create a password.
In the preceding example, 1 is the display number, making the port that you use on the remote host 5901. To create the tunnel, use the “L option in ssh :
% slogin rosalyn -L 5902:rosalyn:5901 joray@rosalyn's password:
In this example, the display number on the local machine is 2. You then tell a VNC viewer to use the local display number 2 by connecting to localhost at display 2 . Figure 14.14 shows the remote host specified in Chicken of the VNC, and Figure 14.15 shows the resulting remote X desktop that is displayed. The remote desktop is running Netscape and an xterm . For some VNC viewers, you may have to use localhost:<display number> as the syntax or localhost:<port number> .For more information on using VNC, see the AT&T and RealVNC sites.
To share your OS X desktop, the procedure is very similar to sharing an X desktop. Use an application such as OSXVnc or Share My Desktop to serve your OS X desktop. When you start one of the applications, you can specify the port to use and set up a VNC password. Share My Desktop does not seem to remember passwords between uses. Then from the client machine, set up an SSH tunnel, as was done in the example involving an X desktop, and connect to the VNC server in a VNC viewer by specifying the host as localhost and listing the appropriate display or port. Figure 14.16 shows an Aqua desktop running Internet Explorer being displayed in a VNC viewer on a Mac OS X machine, and Figure 14.17 shows the same Aqua desktop being displayed in a VNC viewer on a Mac OS 9 machine.
Timbuktu is a commercial application that allows you to view, among other things, a remote desktop and transfer files. It supports the Windows and Mac OS platforms. For more information on the Timbuktu product and to download a trial version, visit http://www.netopia.com/.
Only one vulnerability in Timbuktu has been issued an advisory so far. There have been discussions of older versions of Timbuktu for NT transmitting passwords in cleartext, but no advisory was issued. A preview version of Timbuktu for Mac OS X placed the Timbuktu control icon in the upper left portion of the login screen. Its About Timbuktu menu gave full access to the Apple menu and System Preferences. That hole has since been fixed. If you are interested in security issues regarding Timbuktu, the best place to check is SecurityFocus's Web site, http://www.securityfocus.com/, in that Netopia, the company that produces Timbuktu, watches reports submitted to SecurityFocus's BugTraq mailing list.
Timbuktu Pro 6.0.1 and Older Denial of Service Vulnerability (CAN-2002-0135, BugTraq ID 3918). If a large number of connections are made to Timbuktu, the server no longer accepts connections. No patches have been issued at this time to fix the problem. It is not known if Timbuktu Pro 6.0.2 fixes the problem.
Timbuktu must be installed on the remote host and the local host. Timbuktu has various levels of access, including Public Visitor , Ask Permission , and an authorized user. Create a user and password for each user who should be granted authorized access to the system. For Mac OS 8/9 you can allow incoming access via AppleTalk , TCP/IP , and Direct Dial . Incoming access via AppleTalk is not an option in the Mac OS X version.
Older versions of Timbuktu run as a UDP service on port 407. By version 5.2.x, the default protocol for Timbuktu became TCP, listening on port 407. However, the current versions still listen for connections on UDP port 407 for backward compatibility. You can change the default TCP port by following the instructions available on Netopia's site at http://www.netopia.com/en-us/support/howtodocs/mac/tcpport.html.
Unfortunately, Timbuktu does not allow connections to localhost , making straightforward tunneling over SSH not an option. In other words, Timbuktu can't be forwarded via a tunnel on the client computer. Instead, a tunnel has to be set up on a third computer, and Timbuktu connections can be tunneled through it. The latest version, 6.0.2, advertises a new layer of security with the scrambling of the guest-to-host stream.
Figure 14.18 shows a Mac OS 9 desktop running Netscape being displayed on a Mac OS X machine.
Apple Remote Desktop is another commercial application that enables you to view or control a desktop. It is a UDP application that runs on port 3283. Unlike Timbuktu , it supports only the Macintosh platform. Apple Remote Desktop works on a system of administrative machines and client machines. The administrative machine can observe, control, or lock a desktop or send its desktop to a client for viewing. Additionally, an administrative machine can gather reports involving hardware, software, and so forth on the client machine, copy files, open files, and sleep or wake a client. Some models may give you trouble with sleeping and waking . Make sure the client is capable of choosing to wake for network administrative access. You might find this application especially suitable in a computer lab setting.
No advisories or other comments have thus far been issued regarding vulnerabilities in Apple Remote Desktop.
At this time, the versions of Apple Remote Desktop in use by both the administrative and client machines must be the same. To use software, set up the client machines to be administered. Specifically, set up administrative users for the client, and decide what permission each administrative user has. On Mac OS X clients, you select the appropriate permissions for each real user on the machine who should be allowed such access. You might find it helpful to set up a user whose specific purpose is to allow Apple Remote Desktop access. In traditional Mac OS, you create administrative user accounts within the Apple Remote Desktop application. After the clients are set up, then on the administrative machine create a list or lists of clients to be administered and perform whatever administration needs to be done. Figure 14.19 shows the computer named Tangerine Star being observed . It is currently running Netscape. Figure 14.20 shows a sample of a System Information Report. The items picked to be included in this report include ethernet address, open transport version, IP address, amount of free space, amount of built-in memory, and bus clock speed.