- This topic has 10 replies, 4 voices, and was last updated 11 years ago by
.
-
Posts
-
I installed NX version 403661 on MAC 10.9 and the 403665 on Windows 7.
On MAC I started my user session (first user) and in background another user session (second user).
From the Windows machine I started NX client to open a remote session on MAC.
I used a third user username and password to access MAC, but the opened session was of the background user (second user). This could not happen at all!!
Closing the background session on MAC (second user), and running again NX client on Wndows with the third user username and password on MAC I opened my foreground session on MAC (first user). This also could not happen at all!!In resume , I opened 2 sessions of users without knowing their usernames and passwords and also could not open the right session (third user). This is a complete security flaw. The NX server (with admin privileges) surpassed the OS authentication process and exposed the other users accounts.
A very basic rule of security is that people contact the software vendors before posting in a public forum, so that others can’t exploit the security fault until the fault is fixed by the vendor.
Regardless this problem is a security fault or not, we hope in the future all posters play nice and follow the rules.
We take security very seriously, of course, and the described problem is no exception. But to better understand what the problem is we need to know one thing:
– You say that three users were able to login to the machine. Were these users able to do so without a valid user name and without a valid system password?
– Or all of them had to provide valid credentials for the system (that has these three system users created)?
I have the impression that the problem is just regarding what desktop was presented to them (what Apple calls Fast User Switching). Please, be quick to respond because if this problem is really exposing NoMachine users to a risk, it’s important we react quickly.
When connecting to MAC (from Windows machine) with the third user credential (username and password) I got the screen of the session of the first or the second user sessions already running on MAC. The password of the third user had to be correct. With an erroneous password the connection was not completed.
With 2 running sessions on MAC the connection of the third brought the screen of the second MAC user that was open in background.
Closing the second user session, so only the first user session was running in foreground, repeating the connection with the third user credentials brought the first user active session to the viewing windows machine. In both cases the third user, using its own personal credentials could see the other sessions on windows nx client viewing machine.The problem is that a user could see the session of another user without the credential of that session. I do not know if the security issue is caused by Apple Fast User Switching mechanism or by NX server authentication.
Britgirl, In relation to exposing the problem, It was my first test with nx on MAC.
I was trying to open a remote session to use a MAC session on another non MAC machine, while another user is already using the foreground session.
It is not a hidden or difficult problem to trigger. It is the obvious and immediate operation.I do not know if the security issue is caused by Apple Fast User Switching mechanism or by NX server authentication.
I can confirm that this has nothing to do with the NX server authentication.
The problem is that a user could see the session of another user without the credential of that session.
At the present moment, the remote user logging in with valid credentials is treated like a user sitting in front of the monitor. Even from the point of view of Fast User Switching, this remote user is subject to the same restrictions of a user sitting at the computer. That is, to switch from one session to the other, the remote user needs to re-enter the password. But if the user running the session did not lock the screen, the computer becomes available to the remote user as it would be available to whoever was transiting in front of the computer. This is traditionally the way “remote screen” tools work. I agree that this way of handling the remote user is not flexible and can present a security problem (mitigated by the fact we are talking about a small group of people normally sharing the same Mac). Other users have pointed out the same but NoMachine for Mac is a remote access system not a terminal server.
I used NX 3.5 with linux machines a few years ago. It was wonderful. Remote sessions were opened only with user credentials and without being presented at local display, I also authenticated with my own ssh key. One local user even did not notice that there were other users with graphical interfaces running in parallel. Accessing remotely did not expose the session to whoever could be next the computer. This is an important issue.
Since Linux as desktop have many problems and too much misanderstanding between distributions I migrated to another unix like SO, the OSX. Where I finally integrated my PIN apps with my cel phone and tablet.
Although it is unix , the same behavior does not occur.
It would be nice if it could happen the same way as with Linux. A sharing display app to give remote support is VNC or Teamviewer or RDP. NX should be more than that. An app to really work remotely, not depending on third party internet server authentication, specially now with NSA exposed spying. Who knows if third party authentication servers places back doors to governments or others?
VNC also does not have the graphical quality and security robustness as NX/SSH.
I hope you could improve NX on OSX as it was for Linux.The fact OSX is Unix doesn’t mean it’s Linux. There are things that are trivial to do on Linux that are not as easy on OSX, especially when you are dealing with an OS where what you can do and what you cannot do is written in the EULA.
I used NX 3.5 with linux machines a few years ago. It was wonderful. Remote sessions were opened only with user credentials and without being presented at local display, I also authenticated with my own ssh key.
It’s still like that and even better, given that from the 3.5 to the 4 there have been 6 years of development. But let me summarize: you make a lot of noise for basically nothing and in the end your problem is that now you have to pay a moderate amount for the privilege of running such a (in your words) wonderful terminal server. And of course you want it exactly the same on Mac. And presumably for free. OK, we’ve got the point. Now we’ll get back to work. Thanks for your insightful comments.
But let me summarize: you make a lot of noise for basically nothing
It is not basically nothing. It is a security fault, NX or Apple or another SW. A user may authenticate and use another one account.
and in the end your problem is that now you have to pay a moderate amount for the privilege of running such a (in your words) wonderful terminal server
I did not talk about paying.
This topic was marked as closed, you can't post.