DSM / UVNC crashes with multiuser- cant disable multiuser?

[OwenPigott]

I did post something similar in an existing thread but it would be good to give full details here since this seems like a serious issue that's been occuring for about 2 years from what I can see. There's one issue with this bug that seems to have gone unmentioned though.

It's quite clear from the bug sections of this forum that having multiple connections whilst using the latest DSM Plugin and UVNC Server/Viewer will cause both clients to close without erroring. This will often cause the service on the server to stop.

The issue I cannot see any info on is that there is a multi connections setting within the server settings and there are options to "Refuse the new connection" and "Refuse all new connections". - I can't find any info on what the difference is between these two settings, so if anyone can explain that would be of help.

But setting these does not solve the crashing error.

Can we expect a solution to the whole bug soon? Or just a solution to being able to disable multi connections to stop the bug occuring.

Thanks!

Note: I've encountered a huge amount of difficulties with UNVC and Encryption in particular this last week and i'm thinking this weekend i'll post-up some full details possibly in tutorial form for getting it working since the information is spread around a lot at the moment.

[UltraSam]

These bugs are mainly due to the fact the multi connection while using a DSMplugin are not possible.

Actually it's possible on viewer side (a workaround in the code allows several viewers to be launched using the same DSMPlugin/key on the same machine, each viewer connecting to a different server).

But on server side, as soon as more than one viewer tries to connect to the same server using the same DSM plugin (often MSRC4) then the first connected viewer is dropped and sometimes the server just crashes.

This is because the original DSM plugin code was not designed to be multi-threaded, so the packets from both viewer mix themselevs in the single plugin instance (server side) causing an out-of-sync then a connection drop.

We have modified the DSMPlugin code so it supports multi-threading.
It works with the current TestPlugin and my own personnal DSM plugin.
I have to check what happens with Seans's AES and ARC4 plugins.

One thing is sure: the new MSRC4 multithreaded plugin does not work yet, mainly because of contexts mixes in MS Encryption engine instances, for some obscure reasons as it seems that we do what must be done correctly

BTW, have you tried the "Refuse the new connection" ?

[OwenPigott]

I've tried both Refuse New Connection options - Neither seem to have any affect.

Thanks anyway

[UltraSam]

Will try to take the option into account even before the DSMPlugin can be invoked, which should prevent the problem described above...

[OwenPigott]

Excellent, thanks.

Any idea on the timeframe for a release that will include this?

[UltraSam]

Well... I'd like this modif to be included in the 1.0.3 release...

[blueOrange]

great to see this thread, this is exactly what i am dealing with at the moment. i am currently employing the "MSRC4Plugin_NoReg.dsm" version 1.2.0.0

and i am seeing general bad news when more than one client tries to connect. (clients loose connection, server crashes.)

i have not tried setting the 'refuse new connections' setting yet, but from what others have written it sounds like that doesn't work anyway.

is there a fix AT THIS TIME? I would be happy to move to another version of the plug in, including an earlier version if this would fix the problem. If a second remote user tries to connect, i just want them to be refused, preferably with an appropriate error message that this server is in use and not accepting additional connections.

looks like this problem is well known and had been discussed for at least many months, isn't there a fix yet? I am unsure which version i should be using to address the problem

thanks a bunch.

[UltraSam]

No fix at this time.
I can make a quite workaround to prevent another viewer to drop the previous one connected with the DSMplugin and to possibly crash the server.
Gonna try to do it for the next 1.0.3 RC

The real fix (Multi-threaded dsmplugin support) works with some plugins, but not with the more used plugin: the MSRC4... so I don't release the fix code for now.

[YY]

there is a multi connections setting within the server settings and there are options to "Refuse the new connection" and "Refuse all new connections". - I can't find any info on what the difference is between these two settings

Other than the setting in VNC-server to accept/not-accept mutli connection, the VNC-viewer can also specify the preferrence (at Option screen) of its connection be shared or not at the server.

At server, if you have clicked "Refuse all new connection":
1. First login -- got connected.
2. Later login -- no connection.


At server, if you have clicked "Refuse the new connection":
1. First login -- got connected.
2. Later login, if the viewer has
　　　　- clicked "Share the Server" -- got connected
　　　　- NOT clicked "Share the Server" -- no connection

I also notice two phenomenons:
1. The "Share Server" setting of the first login viewer is not counted, vncserver will only look after the setting of the later comers.
2. If the login is rejected due this reason, the VNC-viewer will just be terminated automatically after password input. There is not any error message returned/displayed.

Finally, the above is talking about the situation w/o DSMplugin, should it be involved, the connected viewer will crash once a new connection come.

[blueOrange]

I really cant believe this is the case! basically, if you want to be secure, ie use encryption, and you have more than one user, the system isn't reliable! ?!

can someone sugest an alternate plugin that provides some level of encryption but doesn't suffer from this show stopper of a bug !?

i just cant believe this is the state of vnc right now ! its not like this stuff is new! what about going to an older version or using a different encryption plug in? my security needs certainly aren't high but would like at least some form of encryption.

is this situation better with other versions of vnc? again, i don't need multiple connections, i just cant have my server crashing if a second person tries to connect !!

also i don't understand why this is a problem with the pluggin. isn't it the vnc server's job to refuse additional connections if thats what it is set to do?

thanks again !

blueorange

[Waltervl]

I also really need (as soon as possible) a solution to this problem !!!

With this problem UltraVNC is too insecure to put on hundreds of unattended servers. We can't afford it to have one of them crashed.

It should be enough that a second viewer will be blocked. In any case something to prevent a crash !

Is there a workaround/solution at the moment ?
If not is there any idea when this problem will be solved ???

[UltraSam]

Yes that's a bug. Sorry.

When DSMplugin is used, if a second viewer connects with the same plugin then the first viewer is dropped. This is systematical.
Sometimes it also makes the server crash (not in my case but it has been reported)

This is NOT a security issue. The server crashes only if the second viewer connects and is identified (which implies that it must provide the good VNC password AND the good DSM encryption key file).
This bug doesn't allow to bypass the encryption requirement or to exploit the server.
This is just an but that can sometimes crash the server so it has to be restarted.

I'm working on a fix to refuse the second viewer connection when a DSM
plugin is used on the server.

Will be in 1.0.3 release.

The "real" fix that allows several viewers to connect with a DSMplugin is done in ultravnc codebase but not yet released as there are some weird behavior with the MSRC4 plugin (due to MSCrypto multithreading/context handling... no yet solved)

EDIT: just finished a first quick fix attempt... will test it deeply this evening and let you know.

[Waltervl]

Thanks UltraSam for your quick response !

I agree it is not a security problem, but it still is an enormous problem if a server goes down and even the whole system crashes with a 'nice' blue-windows-error-screen (error=IRQL_NOT_LESS_OR_EQUAL). Only solution then is to reboot the system with the power-button, but we have a lot of unattended systems. So that's not a good solution.

I'm not sure about what you say about when the crash occurs. I've tested it as follows:
viewer 1 -> connection ok
viewer 2 -> viewer 1 drops, viewer 2 gets “Unknown authentication scheme", viewer 2 presses ok en tries again -> connection ok
viewer 1 tries again -> viewer 2 drops, system crash (viewer 1 only hits the 'connect'-button, dsm-plugin and -key are ok, but password never asked (using ms-loon II)

Has it something to do with the fact that viewer 1 has had already a connection?

By the way. Activating two viewers from the same pc to the same server álways results in a crash of the server and the system where it runs on. Ok, strange test but good for testing the crash

Hope sure the fix will be ready soon !

[UltraSam]

Yep. Thanks for the feedback.

When viewer1 is dropped, it's done the dirty way and the server probably considers it to be still connected, while they are simply out of sync with broken protocol (due to plugin data mix).
So the next time the previously dropped viewer1 reconnects the server falls into a non (not yet) managed case...

For now, with the first fix I try, a second Viewer should'nt be able to connect at all, but the user won't necessarily know why...
(the first thing to do is to avoid the server crash... so I try to prevent the crash )

[UltraSam]

The quick fix seems to work.

When DSM plugin is used on server, a second viewer can't connect and get the well known message with DSMplugin errors enum.

Will be in the next RC and in v1.0.3[/img]

[Waltervl]

Great job UltraSam ! Thanks.

Any idea when the next RC will be ready ?
And the stable release 1.0.3 ?

[petardo]

Hi, RC4 is out since 1st of October but the issue is still there

[UltraSam]

I don't think so.
Can you please check your WinVNC version.
In RC4, a second Viewer simply can't connect when a first one is already connected and the server uses a DSM plugin. No crash. The second viewer is simply rejected.

[petardo]

In RC4, a second Viewer simply can't connect when a first one is already connected and the server uses a DSM plugin. No crash. The second viewer is simply rejected.

Does it relate to the server, or both viewers must be RC4 as well?

[UltraSam]

The problem was on server side. The bug has been fixed on server side
(I was able to reproduce the bug systematically, so the fix is easy to test as well).
Whatever the viewer you are using, if the server is 1.0.4 RC4, the bug shouldn't be there anymore. I just rechecked it again, it seems to work.

[petardo]

Thx. I think the problem was that I insalled only the first packet on my w2k3 server and not the addon which is required for the service (I didn' realize first that the 2nd part is required for the service since the download page - a bit missleadingly - sayes: "Video Driver, Special Service - The Service is required for Vista, Video Driver is optional and for W2000, 2003, XP, Vista" - and my host was w2k3 and not Vista)

[UltraSam]

You're welcome.
We'll try to make more clear the fact that the addons are necessary for Vista.

Thanks for your feedback