Your friendly security team received the following report via mitre.
Please respond ASAP.
The issue is public.

From Debian's bugtracker at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463011

A fix is available from fedora:
http://cvs.fedora.redhat.com/viewcvs/rpms/openssh/devel/openssh-3.9p1-skip-used.patch?rev=1.1&view=markup

======================================================
Name: CVE-2008-1483
Status: Candidate
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1483
Reference: CONFIRM:http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463011

OpenSSH 4.3p2, and probably other versions, allows local users to
hijack forwarded X connections by causing ssh to set DISPLAY to :10,
even when another process is listening on the associated port, as
demonstrated by opening TCP port 6010 (IPv4) and sniffing a cookie
sent by Emacs.

-----

Date: Mon, 28 Jan 2008 23:40:27 +0200
From: Timo Juhani Lindfors <timo.lindfors@iki.fi>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ssh: unprivileged users may hijack forwarded X connections by listening on
 port 6010

Package: ssh
Version: 1:4.3p2-9
Severity: normal
Tags: security

Steps to reproduce:
1) Malice logs to multiuser.example.com
2) Malice runs netcat -l -p 6010 -v -v
3) Alice logs to multuser.example.com and uses X11 forwarding (-X)
4) Alice starts emacs on the remote system (with X forwarding)

Expected results:
3) ssh sets DISPLAY to :11 since :10 would make emacs talk to Malice's
netcat.
4) emacs (xlib) sends MIT-MAGIC-COOKIE to $DISPLAY and Malice can't
see it.

Actual results:
3) ssh fails to listen on port 6010 with ipv4 localhost but does not
try other ports when it can listen using ipv6:

$ sudo netstat -alpn | grep 6010
tcp        0      0 0.0.0.0:6010            0.0.0.0:*               LISTEN     27820/netcat
tcp6       0      0 ::1:6010                :::*                    LISTEN     27823/15

Then ssh sets DISPLAY to ":10" without telling anybody that it is
actually listening only ipv6 and that malice controls the ipv4 port.

4) emacs (xlib) sends MIT-MAGIC-COOKIE to 127.0.0.1:6010 and malice's
   netcat can see it:

listening on [any] 6010 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 58986
lMIT-MAGIC-COOKIE-1...

More info:
1) It seems that specifying "AddressFamily inet" avoids the problem.

2) Easiest way to exploit this is to run "vncserver :10" and allow
anybody to connect to it. When alice starts her emacs it will open its
window to Malice's VNC server and Malice can type M-x shell to run
shell commands with privileges of alice. In fact, I initially hit this
bug when the number of VNC users reached 11 and :10 was no longer
available for ssh causing mysterious failures.


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=C, LC_CTYPE=fi_FI (charmap=ISO-8859-1)

Versions of packages ssh depends on:
ii  openssh-client                1:4.3p2-9  Secure shell client, an rlogin/rsh
ii  openssh-server                1:4.3p2-9  Secure shell server, an rshd repla

ssh recommends no packages.

-- debconf information excluded