(As a result of this misinformation, we almost dismissed the report from our vulnerability scanner as a false positive. There are of course many situations in which this vulnerability is not a problem, and in fact we're considering it a low priority, but in some environments this could have been a serious oversight.)
The descriptions of this CVE on sites like Mitre, Secunia, etc., generally make no mention of xrdp either way, but the way the vulnerability is described could easily lead people to assume that it does not apply to xrdp.
I'm intending to discuss this with some of the relevant organizations, with the intent of either adding references to xrdp to the most prominent online sources or perhaps issuing a new CVE; I'm not sure what the precedent is in cases like this. However, I thought I should discuss it with you first, in case you wanted to coordinate, or be CC'd in, or whatever.
We have an rsa key generator tool to produce a new rsa key for xrdp server usage.
That's xdrp-keygen, right?
Looking at the code,
the key generated by this tool is signed by the well-known private key,
in exactly the same way as described in the original vulnerability
report. Microsoft's RDP client, at least, will take this signature to
mean that the server's key is allowed to change, and presumably other
clients such as rdesktop do the same for compatibility.
Does anybody know what happens if you feed xrdp a
self-signed or genuinely-signed key? (Is there actually any way to do
so? It doesn't look as if the key is stored in a standard format.)