Bugzilla Bug 53226

I saw this in my recent SANS @RISK email.

04.22.13 CVE: Not Available
Platform: Cross Platform
Title: XFree86 XDM Configuration Setting Bypass
Description: xdm is an X11 window display manager. xdm has been
reported to ignore its "DisplayManager.requestPort" configuration
setting. Even if set to false, xdm will open its "chooserFd" TCP
socket on all network interfaces, which could lull the user into a
false sense of security.
Ref: http://bugs.xfree86.org/show_bug.cgi?id=1376

Did some more searching and found this site that talks about it also.

http://xforce.iss.net/xforce/xfdb/16264

CAN-2004-0419
Patch is attached on the xfree86 bug link (see URL)

xfree team : could you please apply that patch ? How do you think we can release this, as latest versions are masked ?

I'll get back to you later tonight.

The easiest thing for me to do would be:

1) Make a new ~arch xorg-x11-6.7.0-r1 with this fix, among others (I already had this in the works)
2) Add it to the current half-stable xorg-x11-6.7.0 and stabilize on any remaining arches, including x86.

This will leave any users of stabilized xorg-x11-6.7.0 (which include ppc, sparc, arm and amd64 users) without an automatic upgrade until 6.7.0-r1 is stabilized. I think this may be justified, given that this only affects users of xdm and really is minor -- not an exploit in the usual sense. All ~arch users on all arches and all other stable users would be upgraded automatically.

On the xfree side of things, the easiest thing would be:

1) Add it to xfree-4.3.0-r5, again no bump. 

For the same reason above, I find it a little difficult to justify a revision bump for this. People who want this fix can read the security advisory and remerge it. Because of a portage bug in dependencies, I'm unable to unmask xfree-4.3.0-r6 as-is, but I have trouble justifying this as a bump on its own.

Fortunately the licensing on this file in XFree86 is fine, so there's no problems moving the fix over.

ETA on this from my side: ~3-4 days (Friday 1700 UTC)

Please confirm or comment.

Donnie --

Reading the ISS release (referenced in the first comment) it specifically says, "A remote attacker could exploit this vulnerability to gain access to the system."  Is this accurate?  If so, I'd say it justifies a version bump for both xorg and xfree.

This will allow a remote attacker to connect to the port, but that attacker
must still authenticate as a local user would. It essentially prevents one from
disallowing XDMCP requests.

So, if a user happens to use xdm (many users don't use any *dm, and if they do,
it's rarely the ugliest one of all -- xdm), they're unable to prevent remote
authentication to xdm without blocking ports via some other scheme, e.g.
iptables.

But if you think a bump is justified, I'll go ahead and do so. Your call.

From the xdm man page:
       To disable listening for XDMCP connections altogther, a line of  LISTEN
       with  no addresses may be specified, or the previously supported method
       of setting DisplayManager.requestPort to 0 may be used.

Summary:
From a technical standpoint, this isn't what I would call an exploit -- it
isn't free access into the system, it requires knowledge of a valid login. It
prevents one from stopping remote logins.

This will allow a remote attacker to connect to the port, but that attacker
must still authenticate as a local user would. It essentially prevents one from
disallowing XDMCP requests.

So, if a user happens to use xdm (many users don't use any *dm, and if they do,
it's rarely the ugliest one of all -- xdm), they're unable to prevent remote
authentication to xdm without blocking ports via some other scheme, e.g.
iptables.

But if you think a bump is justified, I'll go ahead and do so. Your call.

From the xdm man page:
       To disable listening for XDMCP connections altogther, a line of  LISTEN
       with  no addresses may be specified, or the previously supported method
       of setting DisplayManager.requestPort to 0 may be used.

Summary:
From a technical standpoint, this isn't what I would call an exploit -- it
isn't free access into the system, it requires knowledge of a valid login. It
prevents one from stopping remote logins.

I've just added xorg-x11-6.7.0-r1.ebuild. It needs to get to this keyword
status:
KEYWORDS="~x86 ppc sparc ~mips ~alpha arm ~hppa amd64 ~ia64"

That's what the previous 6.7.0 had.

xfree-4.3.0-r6 is now a security update from 4.3.0-r5. The former 4.3.0-r6 with
lots of changes has become -r7.

4.3.0-r6 needs the following keywords:
KEYWORDS="x86 ppc sparc alpha mips hppa amd64 ia64"

Currently it is ~x86 only.

I'm heading out of town for the weekend -- if there's anything more you need
from X people, please ask seemant. You'll have to CC him, as he's not on the
xfree alias.

xorg 6.7.0-r1:

ppc sparc arm amd64: please mark stable
mips alpha hppa ia64: plase mark ~


xfree 4.3.0-r6:

x86 ppc sparc mips alpha hppa amd64 ia64: please mark stable

xfree-4.3.0-r6 & xorg-x11-6.7.0-r1 are now keyworded ~sparc.  The keyword for
xfree applies only
for the security update: because xfree is deprecated for sparc, which is
following the xorg-x11 branch for X11.

no need to cc me, I'm on the security alias.

Keyworded on alpha.

arm/hppa should be all set

mips is all good now

xorg-x11-6.7.0-r1 is stable for sparc.  xfree on sparc is deprecated, but
marked ~sparc.

By the way, you might want to refrain from using my comments for the security
advisory. I'm not absolutely sure that's right, and 90% just isn't good enough.
Probably base it off the other advisories instead.

Stable keywords still needed :

xorg 6.7.0-r1: ppc amd64 ~ia64
xfree 4.3.0-r6: x86 ppc hppa amd64 ia64

xorg-x11 stable on amd64

xfree-4.3.0-r6 marked stable on amd64

xorg-x11 marked ppc

xfree-4.3.0-r6 stable for hppa, sorry for the delay.

Keywords still missing :

xfree 4.3.0-r6: x86 ppc ia64
xorg 6.7.0-r1: ~ia64

x86, ppc : please mark stable so that the GLSA can go out.

GLSA is drafted; we're just waiting for stabilization now.

x86, ppc: We're waiting on you.

If I don't CC myself on this I'll lose track of it in the rest of the security@
mail ...

ok, I've marked xfree-r6 and xorg-r1 stable on ia64

ok, I've marked xfree-r6 and xorg-r1 stable on alpha and ia64

xfree -r6 marked ppc

Marked stable on x86 by klieber two days ago. Ready for GLSA publication.

GLSA 200407-05