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

[Rick Stout]

Rick Stout wrote:
> 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. 

I missed something here. It connects to ssh using the 
/etc/nxserver/users.id_dsa key which it's corresponding public key has 
been added to the users authorized_keys2 file.

> 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.
> 
> 
> _______________________________________________
> FreeNX-kNX mailing list
> FreeNX-kNX at kde.org
> https://mail.kde.org/mailman/listinfo/freenx-knx
> 
> 
>