Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 62912 - net-misc/nxserver-freenx: certificate vulns and passwords in logs
Summary: net-misc/nxserver-freenx: certificate vulns and passwords in logs
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B1? [noglsa] jaervosz
Keywords:
: 72634 (view as bug list)
Depends on:
Blocks: 63757 76387
  Show dependency tree
 
Reported: 2004-09-05 04:18 UTC by Alex
Modified: 2005-05-16 05:59 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2004-09-05 04:18:54 UTC
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.
Comment 1 Alex 2004-09-05 04:22:49 UTC
OOps, I forgot the ebuild:

nxserver-freenx-0.1

Comment 2 Stuart Herbert (RETIRED) gentoo-dev 2004-09-06 13:42:11 UTC
Have you tried connecting w/ nxclient after creating new DSA keys?
Comment 3 Alex 2004-09-09 04:44:35 UTC
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.
Comment 4 Alex 2004-09-09 04:56:44 UTC
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!

Comment 5 Stuart Herbert (RETIRED) gentoo-dev 2004-09-09 12:10:02 UTC
I've raised these points UPSTREAM, and package masked all NX server versions for the moment.

Best regards,
Stu
Comment 6 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2004-09-09 12:27:34 UTC
Stuart thx for the notification.

This is a security issue reassigning.
Comment 7 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2004-09-09 12:33:01 UTC
Ok, now reassigned. Sorry for the noise.
Comment 8 Alex 2004-09-09 13:01:19 UTC
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.
Comment 9 Stuart Herbert (RETIRED) gentoo-dev 2004-09-09 13:19:30 UTC
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
Comment 10 Thierry Carrez (RETIRED) gentoo-dev 2004-09-11 03:03:31 UTC
This is a ~ package, downgrading severity since it's now masked.
Comment 11 Stuart Herbert (RETIRED) gentoo-dev 2004-09-12 02:22:14 UTC
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
Comment 12 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2004-09-15 00:31:24 UTC
Stu if this solves the problem, the package should be unmasked again.
Comment 13 Alexander Weber 2004-09-15 07:24:28 UTC
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!
Comment 14 Stuart Herbert (RETIRED) gentoo-dev 2004-09-15 11:37:08 UTC
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
Comment 15 Thierry Carrez (RETIRED) gentoo-dev 2004-09-15 11:45:03 UTC
Then we're done from a security POV. ~ package, no GLSA.
Comment 16 Stuart Herbert (RETIRED) gentoo-dev 2004-09-15 11:53:49 UTC
The commercial nxserver (all versions) are still vulnerable.  They were stable until package masked.

Best regards,
Stu
Comment 17 Thierry Carrez (RETIRED) gentoo-dev 2004-09-16 05:50:48 UTC
If nothing comes from upstream, we might need a masking GLSA.
Comment 18 Thierry Carrez (RETIRED) gentoo-dev 2004-09-22 09:03:57 UTC
Decision not to issue a mask GLSA, waiting for upstream to fix.
Comment 19 Stuart Herbert (RETIRED) gentoo-dev 2004-09-22 10:42:05 UTC
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
Comment 20 Stefan Schweizer (RETIRED) gentoo-dev 2004-11-10 12:58:25 UTC
Nomachine released version 1.4
Comment 21 Thierry Carrez (RETIRED) gentoo-dev 2004-11-16 02:24:26 UTC
Stuart : please confirm this new version is fixed and provide new (unmasked) ebuilds if you can...
Comment 22 Stuart Herbert (RETIRED) gentoo-dev 2004-11-23 06:24:27 UTC
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
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2004-11-27 11:18:17 UTC
*** Bug 72634 has been marked as a duplicate of this bug. ***
Comment 24 Thierry Carrez (RETIRED) gentoo-dev 2004-11-27 11:21:01 UTC
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 :)
Comment 25 Craig Bradney 2004-12-01 00:45:25 UTC
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
Comment 26 Craig Bradney 2004-12-01 01:06:32 UTC
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?
Comment 27 Craig Bradney 2004-12-01 01:48:28 UTC
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.)
Comment 28 Martin Honermeyer 2004-12-01 03:44:01 UTC
Tried 0.2.7. Works fine for me with a version-bumped ebuild.
Comment 29 veezi 2004-12-01 14:04:12 UTC
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!
Comment 30 veezi 2004-12-01 14:30:42 UTC
I made a typo in comment #29 above. Referenced bug is bug 71522
Comment 31 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2004-12-30 11:57:46 UTC
Stuart any news on this one?
Comment 32 Stuart Herbert (RETIRED) gentoo-dev 2004-12-30 14:16:05 UTC
Sorry, all my time has gone into other things.  I'll get to this in a week or two.

Best regards,
Stu
Comment 33 Joseph Wenninger 2005-01-31 12:22:47 UTC
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 
Comment 34 STefan 2005-02-04 14:27:25 UTC
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.
Comment 35 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-02-04 22:41:50 UTC
STefan you're correct. 

If anyone have an updated ebuild feel free to submit it on this bug.
Comment 36 STefan 2005-02-05 07:33:41 UTC
The latest ebuild 0.27 in portage is fine and doesn't have this problem.
Comment 37 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-02-13 05:20:36 UTC
Stuart do you have time to care of this or should we ask for a new maintainer?
Comment 38 Stuart Herbert (RETIRED) gentoo-dev 2005-02-13 11:04:46 UTC
Anything < freenx-0.2.8 is insecure.  There will be a disclosure + updated packages sometime this week I'm told.

Best regards,
Stu
Comment 39 Thierry Carrez (RETIRED) gentoo-dev 2005-02-28 08:40:50 UTC
Putting this back into main scope, as 0.2.8 is unmasked. We should probably do a GLSA about it ?
Comment 40 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-03-04 01:28:08 UTC
Turns out it was never stable -> closing without GLSA.
Comment 41 Thierry Carrez (RETIRED) gentoo-dev 2005-03-04 06:26:11 UTC
Really closing
Comment 42 Martin Gramatke 2005-04-01 11:22:43 UTC
If this problem is fixed, why is nx still hard masked?
Comment 43 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2005-04-11 23:22:05 UTC
Because bug #83560 is still open.
Comment 44 Jeff Mitchell 2005-05-16 05:59:48 UTC
nxserver-personal uses build 1.4.0-107, which supposedly fixes bug 83560. Can nxserver-personal be unmasked?