xserver is left wide open during install.

[rew]

** I noticed this on Intrepid, but Jaunty might be the same. 8.04 SHOULD also be fixed if it turns out to be vulnerable.

The Xserver is left unprotected during the install.

The consequenses are that someone could connect and trace keystrokes, possibly catching a password. Another way to exploit this would be to connect, and pop up a convincing: 'we need your password to finish the installation' or something like that.

I have a script on another computer that will create a popup on my workstation when something happens. I had the popup on the "installation is finished, click here to reboot".

This was on an 8.10 (intrepid) install, I haven't checked how jaunty fares.

(the story goes, that it took much longer to download and install the patches for XP than it took on average for an "out of the box" XP system to get infected. )

[Kees Cook (kees)]

Thanks for your report! Can you provide detailed steps for how to reproduce this issue? Thanks!

[rew (r-e-wolff)]

Ehh. I just started an install. The Default commandline for X when the system is installed and up is

   /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7

so it doesn't listen to tcp connections on HOSTNAME:0.0 however during the install it seems the "-nolisten tcp" isn't passed, so it does listen, and apparently the -auth is also left out, so clients can freely connect.

To reproduce I did the following.
Download jaunty install image (x86).
Add iso image to virtual box cdrom images.
Create a new Virtual box.
attach cdrom image above.
change network settings to HOST INTERFACE, chose pan0.
on host:
   ifconfig pan0 192.168.240.1

Add:
   subnet 192.168.240.0 netmask 255.255.255.0 {
     range 192.168.240.100 192.168.240.200;
     option routers 192.168.240.1;
  }
to /etc/dchp3/dhcpd.conf

start dhcpd.

(I enabled forwarding and NAT for the packets from pan0, on my host, to be able to verify networking on the installed systems, but I believe this is unneccesary to reproduce).

Next I started the VM.
I selected "install ubuntu".
I followed the install to the "WHO ARE YOU" screen. (I suspect a few steps earlier doesn't make a difference, but I made a typo so it didn't work in my test when I tried it in the earlier screen....).

I then did on the host:
  setenv DISPLAY 192.168.240.101:0.0
and
  xterm &

and got an xterm on my installing system. If this is the first box you're installing on vbox, it's IP address is likely to be 192.168.240.100, so you'd have to change the display accordingly.

Note that I'm installing on a virtualbox now to allow me to reproduce it without having to halt/reboot/reinstall working machines. I noticed the problem on a real install on a real machine which is now back in service (i.e. no longer available for wiping the HD and reinstalling).

If you're trying to reproduce this problem on a real machine on a real network, you just have to make sure that dhcp is somehow running (usually already the case), and figure out the assigned IP address.

Note that for demonstration purposes I started an xterm. This just gives you a window on the host where you issued the xterm command, and not on the machine that is being installed. However, a keylogger could be started, and the contents of the "who are you" screen is very interesting, as it contains the login name of the root-user. The keylogger (if possible, I don't have one, but know they exist) would also capture the password. But even
   xwd | xwdtopnm > test.ppm
  gqview test.ppm

gives a nice screenshot of the machine being installed.

[rew (r-e-wolff)]

I understand you changed the "package" to "xorg". I doubt that the "xorg" package is involved. It's the ubuntu-install-environment that apparently does the wrong thing, while the xorg-package, which is installed on the target system actually DOES do the right thing.

[Evan (ev)]

As of Lucid, ubiquity passes -nolisten tcp. Marking as fixed.