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

[Rick Stout]

Ok, this is getting out of hand. It breaks down like this: Having a user
id and pass{word|key} to an SSH server gives you the properties allowed
to that user and permitted by the server. Using a normal ssh client to
connect to a machine running (free)nx will allow you to use the services
provided by ssh to do things such as port forwarding(most distributions
have port forwarding enabled by default). At minimum, any user using the 
default key *NEEDS* to disable port forwarding.

(BTW, for those reading that need that setting, add this to your 
/etc/ssh/sshd_config:

AllowTCPForwarding no

)

It wont take long for script kiddies to pick up this fact and start
adding nx to the list of users tried when doing ssh scans. When they
find an nx box with the default key, they could have an available proxy.
I think we need to look at this from a different angle, though...

Is it a good idea to give an intruder a place to start? Having a user id 
and key gets you past SSH's authentication, effectively bypassing it. At 
that point, you are technically limited to the shell capability and its 
authentication method, but even if you are secured from port forwarding, 
an exploit to the nxserver or bash/sh (nxserver is a script requiring 
some sort of shell instance) *could* allow root access. (For example: It 
is not unheard of to have a buffer overflow cause some code to be 
executed as another user).

There *is* a problem here. Widely distributing the same key could very 
possibly cause a multitude of security concerns. Varying the key per 
installation can mitigate some of these problems, but not all of them. 
Its like the old saying: Two people can keep a secret when one of them 
is dead... Sharing the key opens a bunch of problems.

To answer the question on how nx connects in SSL encryption mode, it 
goes a little something like this: (Someone please correct me if I miss 
something)

An SSH session is started to the server as user nx with the client dsa 
key. The client also sends a user id and password for the server system 
which is verified by PAM. The startsession command is then passed to the 
nxserver shell, which starts a loopback ssh session as the pam 
authenticated user. nxnode is called with --startsession as that user, 
and nxagent is called starting a forwarding agent through the ssh 
instance. nxnode continues by starting the windowmanager session or 
application that you specified through the client. Meanwhile the client 
is told by nxnode what port to connect to locally and starts an X server 
that receives the information from nxagent.

Non SSL encryption mode differs in that the nxagent doesnt forward 
through the ssh session, but opens ports starting at 5000 for the client 
to connect to.

My take on all of this is that if you only have one user, use only ssl 
encryption mode and you are not using the default key, there is very 
little *insecure* about this. But there are some further concerns that 
need to be addressed.