NX Security (was [FreeNX-kNX] Re: got: "cannot create directory `/home/.nx'")

Rick Stout zipsonic at gmail.com
Tue Oct 19 22:22:01 UTC 2004


freenx at mikebell.org wrote:
> On Tue, Oct 19, 2004 at 06:59:17PM +0200, Kurt Pfeifle wrote:
> 
>>A considerable number of people think that the "--setup-nomachine-key"
>>makes their NX server a tad bit less secure. OTOH, it also makes its
>>use a bit more comfortable. Security and comfort are here, as always,
>>two goals that are not easy to meet at the same time. It is up to you
>>to decide what you want to do. The FreeNX default is to not use the 
>>"--setup-nomachine-key" automatically, but only if you request it by
>>explicitely typing it in.
> 
> 
> 
>>Please!! This isn't giving you access to a "server". That's how FUD 
>>is originating (even if you don't intend it, Rick!)-- It gives you 
>>access to a *login prompt* (where you still have to know the username
>>and password to get in).
> 
> 
> Correct me if I'm wrong, but I'd say a fair analysis of the security
> situation is as follows:
> 
> The setup shares SSH's transport mechanism, therefore provided one
> always uses "ssl encryption", and provided it functions as I've been
> lead to believe it does, one is dealing with just SSH here.
> 
> However, it almost completely bypasses SSH's authentication mechanism.
> This means that any exploit in nxserver/freenx is exploitable by anyone
> with the NX user's key, a set of people which may range from effectively
> everyone in the case where the nomachine key is used, to only trusted
> users in the case where the key was tightly controlled and no one ever
> used it from an untrusted machine and it never leaked in other ways.
> 
> A compromise of freenx in this fashion would give you a local,
> restricted shell account. However in addition to being able to turn
> around and apply a local root exploit, you also have the quite useful
> capability to monitor all the cleartext passwords of people trying to
> log in using nx sessions, as well as all their keystrokes (and hence
> even more passwords), again without the need for a local root exploit.
> 
> Finally, one very important detail is that sshd allows things like
> unrestricted port forwarding to anyone who can log in, a problem that
> anonymous CVS over ssh and various other services deal with by disabling
> it altogether. However, while no one replied to my email on the subject,
> I would not be surprised if NX relies on this behaviour being enabled
> for the nx user in order to function.
> 

I didn't think of this, but that is correct. And this was exactly the 
type of problem I was talking about.


> If that is the case then installing NX means that you're turning your
> computer into an anonymous relay (spamming, covering one's tracks when
> breaking into further systems, etc) for anyone with your nx key. No
> exploit of freenx required.
> 
> All in all, this NX server stuff is far from the unmitigated security
> disaster it seems to have been painted as by some, but I personally
> would be disinclined to trust it until it has been documented in detail
> and looked over by people more knowledgable than myself. Especially in
> the case of freenx, since it's virtually impossible to safely handle
> untrusted data in a shell script, as they try to do.
> _______________________________________________
> FreeNX-kNX mailing list
> FreeNX-kNX at kde.org
> https://mail.kde.org/mailman/listinfo/freenx-knx
> 
> 
> 



More information about the FreeNX-kNX mailing list