The ebuild uses a static key for $NX_ROOT/home/nx/.ssh/authorized_keys2 which is the public part of the private key installed by nxclient in $NX_ROOT/share/client.id_dsa.key. This is a great security risk. Every Gentoo user can connect to the nxserver of another Gentoo user who installed FreeNX and if there ever is a security bug in nxserver's user authentication one can easily break into all Gentoo systems using FreeNX. The nxserver ebuild should create a new dsa_key and install this one or at least print a warning that these keys have to be replaced in a production environment. Reproducible: Always Steps to Reproduce: 1. install nxserver-freenx on one machine 2. install nxserver-freenx on another machine 3. install nxclient on a client machine 4. copy $NX_ROOT/share/client.id_dsa.key from one of the servers to the client machine. 5. connect to both servers Actual Results: I can connect to the nxserver and start guessing passwords of users or if there is a security bug in nxserver i can break into the host. Expected Results: Create new dsa keys.
OOps, I forgot the ebuild: nxserver-freenx-0.1
Have you tried connecting w/ nxclient after creating new DSA keys?
Yes, I tried using my own keys and it works great but I had to recreate my nx-users. But there is another problem which is far more severe. I didn't test nxserver-freenx 0.2 and don't know which security settings changed in the new version but v 0.1 has the following problem, too. Suppose you have multiple users which want to use freenx. You install the client and copy the dsa key /usr/NX/share/client.id_dsa.key to your home directory .ssh/id_dsa. The command nxserver -adduser just copies the public part of the client.id_dsa.key to your server .ssh directory as authorized_keys2. Now you have the following problem (EVEN IF YOU CREATED YOUR OWN KEYS!): As every user uses the same key and therefore the same password (if you set one on the key). Everyone can make an ssh connect as ANY registered NXServer-user. Example: You have the users joe and john. Both use freenx and both use the same dsa key as nxserver doesn't seem to support keys per user. If JOE does a 'ssh john@nxserver' he can immidiately connect as user JOHN because he has the required dsa public key on the server and the private key from the nx-client-installation in his home directory. The same is true for user JOHN who can connect to the server as user JOE for the same reasons. I hope this has all changed in nxserver-freenx 0.2.
Just another warning for users who have installed freenx 0.1 and didn't change the original keys: To put this all together you now have an installation which is wide open. Everyone who downloads the official nxclient can now connect to your server as any registered nx user without being ever asked for a password!
I've raised these points UPSTREAM, and package masked all NX server versions for the moment. Best regards, Stu
Stuart thx for the notification. This is a security issue reassigning.
Ok, now reassigned. Sorry for the noise.
UPDATE: On creating my own keys I accidently overwrote the user id_dsa keys too and therefore I was able to connect as any user. It is not true that any nx-user can connect diretly per ssh as any other user. This was all my fault. Sorry for the noise. The problem that you can do an nx-connect IS true. But you still need a password to auth as a normal user.
And I was looking forward to a quiet night too :) I've done some testing of my own, and discussed this with UPSTREAM too. server.id_dsa and client.id_dsa are used by nxclient to log into nxserver/freenx only. These keys are static keys, easily obtainable from the Internet. nxserver appears to allow an infinite number of password guesses per user, as does FreeNX. This makes nxserver and FreeNX less secure than standard UNIX login - but the h4x0r still has to successfully crack a password to gain access. FreeNX 0.2 has attempted to address this by providing PAM based authentication. I've had no luck getting this to work w/ FreeNX 0.2; I'll be testing FreeNX 0.2.1 later tonight. Note that PAM based authentication doesn't seem happen if you've added a user to the nxserver database by using nxserver --useradd. I still need to look into that. We might need to patch FreeNX to enforce PAM based authentication. That's one issue addressed. -- The second issue is the key that is added to each user's authorized_keys2 file. This key is generated when nxserver / FreeNX is installed. It is called user.id_dsa, and can be found in /usr/NX/etc. The private component is chmod 600, and chown nx. The public component is added to each user's authorized_keys2 file when the administrator runs nxserver --useradd <user> The nxserver process uses the user.id_dsa key to log into the local machine as the user, by running the nxssh command. As far as I can determine, the private user.id_dsa key is never transmitted over the network. The only ways that the private key can be obtained are a) the administrator gives the key to someone, or b) someone develops a remote exploit against nxserver It would be preferable if nxclient supported per-user keys, like a traditional ssh client does, but the way things work at the moment is not insecure. Best regards, Stu
This is a ~ package, downgrading severity since it's now masked.
FreeNX 0.2.3 includes my 'nxkeygen' utility, which replaces the stock NoMachine key with a unique key for the local server. Best regards, Stu
Stu if this solves the problem, the package should be unmasked again.
1) perhaps the ebuild should mention the existence of nxkeygen, or better directly use it if not explicitly surpressed by the user (with a local use variable 'noownkey' perhaps?) 2) The nxkeygen works nicely, but it did not mention that the user has to replace the key in /usr/NX/home/nx/.ssh/authorized_keys2 with the new one!
FreeNX 0.2.4 does solve the problem. Still no solution (and alas, no response yet) for NXserver commercial version. I'm leaving FreeNX masked because of problems with the functionality. Best regards, Stu
Then we're done from a security POV. ~ package, no GLSA.
The commercial nxserver (all versions) are still vulnerable. They were stable until package masked. Best regards, Stu
If nothing comes from upstream, we might need a masking GLSA.
Decision not to issue a mask GLSA, waiting for upstream to fix.
At the moment, it would appear that NoMachine will not release a fix for nxserver-1.3.2. nxserver-1.4 will include a fix when it is released. Best regards, Stu
Nomachine released version 1.4
Stuart : please confirm this new version is fixed and provide new (unmasked) ebuilds if you can...
Hi, I'll post an update as soon as I've had time to add 1.4.0 into Portage. I'm not sure whether it does contain a fix or not. Best regards, Stu
*** Bug 72634 has been marked as a duplicate of this bug. ***
Please also note the following, reported on bug 72634 that was just merged with this one : From <veezi@hotmail.com> With logging enabled. Connecting from nxclient with 'Windows' desktop will log the user password in clear text in /tmp/nxserver.log. Looks like it won't be the last vulnerability found in nxserver-0.2.x :)
Some notes I got talking to someone close to the project: Current version has made security stronger. But I never heard of that "clear password in log" /tmp/nxserver.log was written by an early version of FreeNX. And it must be enabled for debugging. (Though I guess if you dont want to debug, you can remove it???) /tmp/nxserver isnt used by NoMachine NX
BTW, has anyone tried freenx 0.27? Although I'm looking for !M NX as I have a licence, some concerns might be covered for freeNX with the newer release. Has 1.4 been tested yet?
So.. some more comments. [10:44] Oh, F***, F***, F***!!!! [10:44] Why the hell is the same FUD now surfacing again, which was already answered 2 months ago?? [10:44] . [10:44] I read that Aley-boy's beginning of a "bug-report". That guy doesnt understand a thing. He just spreads FUD. [10:44] He says "As every user uses the same key and therefore the same password (if you set one on the key). Everyone can make an ssh connect as ANY registered NXServer-user." It is the same FUD as spread by RedHat already a year ago against NX. (RedHat fears competition to their LTSP/VNC servers). [10:44] . [10:44] THIS IS A LIE, a damn lie! [10:44] . [10:44] The facts: there is a special user "nx" on each NX server. That user doesnt have a shell, and no "normal" account. That user is simalar to user "wwwrun" for Apache. That user *initiates* the NX session on behalf of the real NX user WHO STILL NEEDS TO AUTHENTICATE USING HIS PRIVATE CREDENTIALS once the NX session is successfully initiated. [10:44] . [10:45] The "nx user" uses a static key to just initiate the session. Of course, if you guess the password of an NX user, you can connect as the NX user. But then, if you guess any non-NX user's password, you can connect to that user's accounts too.... [10:45] . [10:45] A static key allows you to connect (==initiate a connection) to your server from any client, on any platform. You can also generate a "per NX server" key. In that case you must distribute the key's counterpart to any potential client prior to his first connection. (But that client of course still needs his own password and still needs to protect it.)
Tried 0.2.7. Works fine for me with a version-bumped ebuild.
Version 0.2.7 works fine here also. All I did is: 1. Version bump the ebuild 2. Fix the nx-x11 ebuild (for proper lib installation) as indicated in bug 72634 3. Fix the nxserver script (added $NX_DIR/bin to nxnode-login in line 490) as indicated in bug 72634 Some things to note: 1. I don't see the password logged anymore in clear text when I enable logging and try a windows desktop connection with supplied RDP credentials. 2. There're still some running bash and ssh processes after closing the connection. Even after a long time. Don't know if this is a problem or by design. Is there anything else that one needs to test with this new version (as compared to 0.2.4)? Overall it's such a great work. I could never imagine working on X remotely over a modem link with such responsiveness. Really amazing!
I made a typo in comment #29 above. Referenced bug is bug 71522
Stuart any news on this one?
Sorry, all my time has gone into other things. I'll get to this in a week or two. Best regards, Stu
Is there any progress. It would be nice to have a working nx server/client ebuild. What's the planned solution to the problem that at least with a default installation a man in the middle attack is quite easy during the login process, since the private and the public key are well known. Just creating a new keypair instead of the default one during emerging or is there another solution ? Or do I miss something about the security issues
Yes you are missing something, without a real user account + password on the nxserver machine you cannot login, just like you do normal ssh and that is no security risk either, is it? Pam auth was introduced as far as I know in 0.2 version, so this issue here was solved long time. I'm not sure why this report ist still open, but it looks like this ebuild is not actively maintained at the moment.
STefan you're correct. If anyone have an updated ebuild feel free to submit it on this bug.
The latest ebuild 0.27 in portage is fine and doesn't have this problem.
Stuart do you have time to care of this or should we ask for a new maintainer?
Anything < freenx-0.2.8 is insecure. There will be a disclosure + updated packages sometime this week I'm told. Best regards, Stu
Putting this back into main scope, as 0.2.8 is unmasked. We should probably do a GLSA about it ?
Turns out it was never stable -> closing without GLSA.
Really closing
If this problem is fixed, why is nx still hard masked?
Because bug #83560 is still open.
nxserver-personal uses build 1.4.0-107, which supposedly fixes bug 83560. Can nxserver-personal be unmasked?