Cve-2008-3259

Hi, I just have a quick/probably dumb question about this vulnerability...

"OpenSSH before 5.1 sets the SO_REUSEADDR socket option when the X11UseLocalhost configuration setting is disabled, which allows local users on some platforms to hijack the X11 forwarding port via a bind to a single IP address, as demonstrated on the HP-UX platform."

Hi,
This is definitely not a dumb question.
I looked at the corresponding OSVDB Id and the information provided in the Open SSH change log for the version where it was fixed. Some more information is here.
For this example, let us assume there is an SSH server with an Ip Address of 192.168.0.1. The SSH server is configured to forward X11 connections.
A user logs in to this SSH Server with X11 forwarding enabled. Typically, to forward the X11 connections, it by default binds to localhost (127.0.0.1) and to a specific port, like 6010. (The DISPLAY variable is automatically set to this set of data).
Now, if this version of SSH Server had the option "X11UseLocalhost" set to "No", it binds to 0.0.0.0 and also uses the "SO_REUSEADDR" socket option as well while binding.
An attacker could have previously bind to the specific Ip Address (192.168.0.1) and the SAME port (in this example 6010) in that system. When the SSH connection is established, it would have set up a forwarder on 0.0.0.0 and on that port.
NOTE : Usually this was possible on very specific systems such as HP/UX (They do not check for effective user id before connecting or the that the Bind Address are over lapping.) Linux systems do not have this problem - (Check the bug report in redhat).
Now, if the user who logged in just now uses any X11 application, the X11 application instead connects to 192.168.0.1 and port 6010 instead of 0.0.0.0 (the attackers application which is bound to that Ip Address instead of being forwarded over the SSH tunnel). The attacker can now use the hijacked X11 application.
The attacker needs to have local access to the system (be a local user) to be able to run his application which binds to the Ip Address 192.168.0.1. He has to be a local user.
Hope that helps !
Another vulnerability with some similarities is reported in here

However, I am curious to know why you were researching this particular CVE ?

I was researching this for a university project. I had to identify and appraise all possible vulnerabilities that could exist in a particular website as a result of incorrect input validation. I actually had a verbal exam on the vulnerabilities I identified, so I was hoping the examiner wouldn't bring up this CVE (he didn't in the end). Regardless, your help is much appreciated!