Release 1.3.4

[Rudi De Vos]

Download
https://www.uvnc.com/downloads/ultravnc ... 1-3-4.html
links: OK
Source
https://github.com/ultravnc/UltraVNC/releases/tag/1.3.4
link:OK

Changes 1.3.4
rdpmode fix
size/position/dpi update
security fixes
AdjustWindowRectExForDpi fix
scaling changes
Prevent service to restart vnc desktop part when SHutdown has been initiated.
Better result for scaling 200% or 300%
delete ( remove MRU + delete optione files + reset to default)
High dpi_aware
Linux
vnc4server patch update
Fix connection issue with vnc4server in 32 bit color depth.
Fix broken screen color with vnc4server in 32 bit color depth.
Fix broken mouse cursor color in 16 bit color depth.
Fix corruption along mouse cursor trajectory
Fix broken background color in 24 bit color depth (vncviewer).
Fix TightEncode
Fix TigerVNC
rdpmode fix
cleanup old code
Zstd 1.5.0
Possible crash fix ( minidump analyse)
winpe fix
zlib fix
multimouse option
Maxviewers
multiple mouse pointers
On remote resize, left/top of viewer isn't move
fix scale to windows size
last mouse click viewer has controle
On remote resize, left/top of viewer isn't moved
Use singleton for osversion
Disbale touchscreen input when mouse is disabled
Add noacceleration build options
Scrollbar fix
ddengine/scrollbar/ initial cursor ??
Scrollbar fix
viewer maximize/minimize/restore
Fullscreen fixes
span multiple monitors
Allow minimize for non spanned monitors
createpasswd ( secure mode)
Linux
TigerVNC compat fixes
Modify Extended clipboard for TigerVNC
Fix tigerVNC extDesktop compat issue's

[zeiseiwogn]

Hello,
is there a MSI Package Download available?
I cant find it at the Download area on the homepage.

Best Regards
Christian

[TSchm]

Great release so far.

Are there plans to release the MSI installer as well?

[SkyBeam]

First of all thanks a lot for all the effort going into this release by all contributors!

I noticed one thing that bothers me: The viewer now seems to show a warning when connecting to servers without authentication. The connection window with title "Accept serer without authentification" (btw. shouldn't it read "authentication"?) showing a warning sign and the text "The Server has been setup without authentication, do you thrust this server?" (also here I suspect the word "trust" is to be used instead of "thrust".

But my issue here is that this warning also is popping up in case of Repeater Mode II is used (using IDs).
UVNC does not apply any authentication in reverse connection (repeater mode II) mode and as of my knowledge there is no way to activate it. I would actually prefer to use authentication also in reverse connection mode but I think in reverse connection mode authentication is bypassed all the time and now the viewer is printing a warning about it.
So I think at least in reverse connect/repeater connection mode with ID the viewer should not show this warning - or allow to omit the warning by configuration or command-line option.

[priechodsky]

Please MSI installation packages

[Thomas Levering]

reverse connect/repeater

I Use Repeater with encryption plugin and password -> no Warning

One Solution:
click Thrust and write this to "IP".vnc File

[Rudi De Vos]

I will check the "thrust" issue.
Need to be disabled for invers connections.

There was a security issue with fake vnc servers that tried to get access to the viewer pc.
They always answerd noauth and let each viewer in, then they tried to create buffers overrun to execute some code on the viewer.

We added coded to protect the buffers and as extra the warning was added.
The warning should never popup when you use encryption as this prevent the server to send anything to the viewer when he doesn't know the password.

Using invers connection, the password is forced by the encryption.
Only unencrypted connection are without a password in revers connection.

Please check, this viewer allow unencrypted servers in listening and repeater mode
https://www.uvnc.eu/download/134/vncviewer134.zip

[Rudi De Vos]

MSI wil be made after some minor release issue's are solved.

[SkyBeam]

I am not sure if I am doing anything wrong. My Server and viewer are using the SecureVNCPlugin64.dsm and during connection (after accepting unauthenticated connection) the encryption seems to be properly in place. Status window is showing:
Status: Connected (SecureVNCPlugin-v2.4.0.0)
AES-256-OFB(256); RSA-2048

I do however not put any password or keys into my installation, just default configuration. I was assuming the encryption plugin is negotiating the keys on connect. But sure this is not authenticated so I might connect to a "malicious" server technically speaking. However my Server module is "public" so it would be quite useless for me either to put a password into the installer as essentially anybody could use just this public installer to create a connection as it includes the keys or password so anybody could extract it to attack my viewer.
Technically still pretty unlikely as I am the only one having access to the repeater port to connect the viewer and I know when UVNC server is started on the remote machine as I am connecting only to IDs I know.

So in my use-case I would prefer to configure to suppress the warning or use a command-line option to suppress it as the connection is encrypted and authentication wouldn't provide any additional security other than placebo.

[Rudi De Vos]

I was assuming the encryption plugin is negotiating the keys on connect.

Correct. The dsm use DH and primer numbers to pass a key to the other site.

We also use the encryption like this
viewer: generated key + vncpasswd = new key
server: generated key + vncpasswd = new key
When the vncpassword is empty, you still proper encrypt but no authentication

The viewer is proper patched for all known issue and some extra buffer control has been added.
As long as you know what you are doing it safe.

Does this fix it ?
https://www.uvnc.eu/download/134/vncviewer134.zip
Else i need to add some extra parameter in the ini file for.

[SkyBeam]

I am afraid I need a bit of background info.

I am usually using mslogon2 and domain/local user accounts btw.

Here is what I have tested so far.

Direct connection (no repeater, Viewer connects directly on LAN to Server):

• Secure plugin enabled (no password, no keys), mslogon2 disabled: Viewer asks for password configured in "VNC Password" field on server. Status window showing "AES-256-OFB(256); RSA-2048;". No connection warning.
• Secure plugin enabled (no password, no keys), mslogon2 enabled: Viewer asks for username and password in mslogon2. Status window showing "AES-256-OFB(256); RSA-2048;". No connection warning.
• Secure plugin enabled (password defined, no keys), mslogon2 disabled: Viewer asks for password of the encryption plugin. Status window showing "AES-256-OFB(256); RSA-2048;". No connection warning.
• Secure plugin enabled (password defined, no keys), mslogon2 enabled: Viewer asks for username and password in mslogon2. Status window showing "AES-256-OFB(256); RSA-2048;". No connection warning.
• Secure plugin enabled (password defined, public key on server, private key on viewer), mslogon2 enabled: Viewer asks for username and password in mslogon2. Status window showing "AES-256-OFB(256); RSA-2048; Auth(RSA-2048)". No connection warning.

So it looks like the password configured on encryption plugin overrides the "VNC password" which is ignored then. But not if mslogon2 is active which will override the secure plugin password. So when mslogon2 is active the secure plugin password configuration does not have any effect.
Only when keys are used the "Auth(RSA-2048)" annotation is added.

OK, so far it works even though it was a bit unexpected to me to see that the encryption plugin password is entirely ignored in my case (mslogon2 active). It seems to be used only in case plain VNC password is used and I don't really see why we need 2 configuration fields for this in such case. If I want to have a plain password for authentication why does the secure plugin require or even offer an option to override it and not just use the configured VNC password? It actually even does so if there is no password configured in the secure plugin.

The viewer does not show any warning in any case.

Now let's go on to the reverse connect scenario (using repeater mode II with IDs):

• Secure plugin enabled (no password, no keys), mslogon2 disabled: Viewer asks for password configured in "VNC Password" field on server. Status window showing "AES-256-OFB(256); RSA-2048;". No connection warning.
• Secure plugin enabled (no password, no keys), mslogon2 enabled: Viewer does NOT ask for username and password in mslogon2. Status window showing "AES-256-OFB(256); RSA-2048;". Asks to accept connection without authentication!
• Secure plugin enabled (password defined, no keys), mslogon2 disabled: Viewer asks for password of the encryption plugin. Status window showing "AES-256-OFB(256); RSA-2048;". No connection warning.
• Secure plugin enabled (password defined, no keys), mslogon2 enabled: Viewer does not ask for for username and password in mslogon2. Status window showing "AES-256-OFB(256); RSA-2048;". Asks to accept connection without authentication!
• Secure plugin enabled (password defined, public key on server, private key on viewer), mslogon2 enabled: Viewer does not ask for username and password in mslogon2. Status window showing "AES-256-OFB(256); RSA-2048; Auth(RSA-2048)". Asks to accept connection without authentication!

This for me is confirming some weirdness with the mslogon2 authentication. The viewer seems not to be asked at all for any sort of authentication in reverse connection mode in case mslogon2 is active in reverse connection mode and is warning me that I connect without authentication.


Using your attached/patched viewer I get slightly different results in the sense that it does NOT ask me to accept connection without authentication. But sill the same behavior that I am NOT asked to enter username/password as defined in mslogon2.

So I think unless I am misunderstanding something and mslogon2 is entirely disabling any sort of authentication it is broken in 1.3.4 server release for reverse connections.

If I disable mslogon2 it entirely works as expected (as of my understanding). Either asking for the VNC password or (if configured) the security plugin password which overrules the VNC password (which is a bit confusing but at least seems to be as specified). But as soon as mslogon2 is enabled it completely bypasses any authentication. This might be a serious security issue in 1.3.4 release for people using mslogon2, not knowing that reverse connections entirely and unexpectedly ignore/bypass any authentication now.

To be fair I have validated this behavior with UVNC 1.3.2 too and also UVNC server skipping any authentication if mslogon2 is active, but the viewer did not complain about it.

But I think there is a bug (or I don't understand it). Also on reverse connections my viewer should ask me for username/password of mslogon2, just as it actually does if mslogon2 is disabled and it either asks for VNC password or secure plugin password (if configured overruling the VNC password).




So here is a report for something I would call a bug...

Steps to reproduce:

• Install UVNC server 1.3.4 on host A
• Install UVNC viewer 1.3.4 on host B
• Install UVNC repeater accepting mode II reverse connections on host C
• Configure server to use mslogon2 using authenticating local vncusers group
• Configure a user as a member of vncusers group
• Run server with "-id:1234 -autoreconnect -coonnect host-c:port"
• Start UVNC viewer 1.3.4 and connect to "ID:1234" using repeater "host-c:port"

Expected result:
VNC viewer asks for username/password on connect to ID:1234.

Experienced result:
VNC viewer does not ask for any authentication at all and displays warning about connecting without authentication (which seems to be correct).

[Rudi De Vos]

Answer part1, normal reverse connection

So it looks like the password configured on encryption plugin overrides the "VNC password" which is ignored then. But not if mslogon2 is active which will override the secure plugin password. So when mslogon2 is active the secure plugin password configuration does not have any effect.
Only when keys are used the "Auth(RSA-2048)" annotation is added.

Correct:
1° We don't want a double password (long passwd + user + user long passwd)
2° Using user/passwd we first setup the encryption. The key is used for encryption and later insite the AES stream the user/passwd is checked.
Using a seperated key and user/passwd you have a double authentication check ( key + user/passwd), not needed but add some extra layer.

2 long passwords would not make it a lot safer.

[Rudi De Vos]

Repeater
A good thing the warning was added, else we never should have noticed it.
All versions behave the same, it looks like a design issue.
A revers connection should behave the same with or without ID.

This gonna take at least a few weeks to debug, looks like a 134.1

[SkyBeam]

Repeater
A good thing the warning was added, else we never should have noticed it.

I think I have reported this already a while ago but somehow I was pushed to believe this is by design and reverse connections bypass authentication all over by design.
I did however only use mslogon2. By testing now I found that there is indeed supposed to be normal authentication also in reverse connection use-case. So the mslogon2 bypass appears to be a bug.

So yes, I am happy the check was added.

For me it was clear that I need to protect reverse conections better so I assured only authenticated people can even connect clients to the repeater by having to tunnel via SSH connection so only people having SSH access to the repeater node would be able to connect. So at least I would not expose all reverse-connect servers to the public without authentication.

I am glad this is not intended behavior and can be addressed now. Many thanks.

This gonna take at least a few weeks to debug, looks like a 134.1

No worries, this bug seems to be in the code since quite a while and I even was thinking it's by design.

[Rudi De Vos]

A few weeks... LOL

In the code it's explicit disabled for revers connection with a parameter.
Replacing true by false change the behaviour.

https://www.uvnc.eu/download/134/winvnc ... e_test.zip

Do you have time to rerun your test again?

The behaviour change is for repeater and standard revers.
If it works i will add it as an option, chaging default behaviour always upset people.

[SkyBeam]

Many thanks for investigating

Unfortunately the test-build from the ZIP did not do any change. I don't get prompted for any authentication when connecting in repeater mode II. First the viewer displays "Password requested" and then pops up the "The server has been setup without authentication, do you thrust this server?" (note: The wording should be updated in this dialog; see previous comment).

It does not matter if I configure a password in the SecureVNC plugin or not. Authentication is still completely bypassed.

Note: I did test only the 64-bit build.

If there is a boolean flag to enable/disable this behavior I wonder what was the background to do this and perhaps the flag to run without authentication should be a global flag applying regardless of selected authentication module. Like a top-level checkbox in the configuration dialog to enable authentication or disable it while graying out all the options like VNC password and mslogon configuration.

So unfortunately the test build did not change the behavior to me.

[Rudi De Vos]

I tested
viewer
*encryption and listen op 5500
server
encryption + mslogon
"add new client" and connect to viewer:5500

Result, the listening viewer popup a user/passwd

I will do the same with an ID and repeater, this wasn't tested.

[Rudi De Vos]

repeater test
Also popup the user/passwd... perhaps different with commandline, not tested

[SkyBeam]

So something is different in our setup. I even switched to the official Windows repeater (usually for my production setup I need a linux-based solution). But no change. Viewer does not ask for any authentication as soon as mslogon2 is active.

Server Service Command-Line: -id:123451234 -autoreconnect -connect <ip>:5500

I still try to find what might be different in your setup

Also in direct reverse connect mode (Server connects to Viewer listening on 5500) I do not get any password prompt. Are you sure you sent me the correctly modified winvnc.exe?

[Rudi De Vos]

The repeater doesn't change anything, it just pass data from a to b.

Rebuilding to be sure release is same as debug.
64bit version
https://www.uvnc.eu/download/134/winvnc_test2_64.zip

Still need to test to commandline, could be it behave different, but at least you need to have to same effect
if you use the same parameters from the images.

[SkyBeam]

The repeater doesn't change anything, it just pass data from a to b.

That was my assumption as well. I am scratching my head currently on where the problem might be and did more test setup changes. And I think I am getting somewhere.

Now for the first time I have been able to get an authentication prompt using ID (Mode II repeater). The way I did it now is:

• Start VNC Server in service mode
• Manually going into admin properties
• Hit the "Start" button at the "Initiate invers connection section
• Enter Repeater: <ip>:5500
• Enter ID: ID:1234

This is working with my Linux repeater as well as the Windows repeater (just as expected).

Well, but my service is supposed to auto-start so I configure the command line "-id:123451234 -autoreconnect -connect <ip>:5500" but it looks like this is somehow messing with the authentication. All builds entirely skip authentication if command line is used (which should actually be identical to starting "winvnc.exe -service" and then initiating reverse connection manually.

I can perfectly reproduce this now. Whenever I use the "-connect" command-line to auto-initiate a reverse connection on service startup then it totally bypasses any authentication if mslogon2 is active. It does work perfectly fine if the GUI is used to manually initiate a reverse connection.

[Rudi De Vos]

Just tested and the commandline is started from his own spot, passing auth off.
So looks like both test could be correct with the old code.

"-id:123456 -autoreconnect -connect localhost:5500 -run" is the same from cmd, you need to add the -run
to the service_commandline option

Updated
tested
winvnc.exe -id:123456 -autoreconnect -connect localhost:5500 -run

64bit version
https://www.uvnc.eu/download/134/winvnc_test3_64.zip

[SkyBeam]

Updated
tested
winvnc.exe -id:123456 -autoreconnect -connect localhost:5500 -run

Well, did I miss that I need -run all the years? What is it good for and why does it only bypass authentication for mslogon2 but not for other authentication?

I just added -run to my setup and it did not work (still bypassing authentication). I will try with your build now.

EDIT: I confirm that your test build is workin and not bypassing authentication in reverse connection mode initiated on command line when using "-run" additional command-line argument.
EDIT2: It also does not bypass authentication when NOT using "-run". So I don't know if I should use it.

But the latest build seems to have fixed the issue for me.

[Rudi De Vos]

using -run you can simulate the service_commandline, don't add it for the service.

It's simpler to test with winvnc.exe from commandline then actual let the service autoreconnect.
At least for debugging.

Using
service_commandline = -id:123456 -autoreconnect -connect localhost:5500
is the same as
winvnc.exe -id:123456 -autoreconnect -connect localhost:5500 -run

test3 seems to work also for the commandline

[Rudi De Vos]

ok, so i will add it as extra server option.
That's a more work the changing the flag(s)

[SkyBeam]

using -run you can simulate the service_commandline, don't add it for the service.

It's simpler to test with winvnc.exe from commandline then actual let the service autoreconnect.
At least for debugging.

Using
service_commandline = -id:123456 -autoreconnect -connect localhost:5500
is the same as
winvnc.exe -id:123456 -autoreconnect -connect localhost:5500 -run

This clarifies it - however I am still unsure why you would need the "-run" and not just detect the last argument. I never used "-run" as I was never running winvnc.exe on command line but always as service. The documentation is a bit unclear on this:

-run
Need to be the last parameter, tell winvnc that no more
parameters are left

Source: here.

But I am happy I did not misconfigure it and causing this issue. So it seems to me we have found a real issue. Even though only manifesting itself in a very specific scenario (service launched with command-line to auto-initiate a reverse connection AND using mslogon2). Well, not sure how common this scenario is.

test3 seems to work also for the commandline

The test3 build working fine for me too. Using service with command-line for automatic reverse-connection to repeater mode II using IDs.

[Chesser]

Hello!
After upgrading from 1.3.2 to 1.3.4, there was a terrible problem. On computers, after turning them off and then turning on, the service (it is a system one) does not start "uvnc bnca" Although automatic start is selected for this service. All 20 computers are experiencing this problem. Sometimes 2-3 computers out of 20 have the service ... automatically starts, but this is rather an exception. Due to the failure to start the service, the uvnc-server is not automatically activated. Please help me solve the problem. This was not the case in previous versions.

[Rudi De Vos]

Service

This doesn't seems to be something general we can repeat on our site.
To find what happen we need info from your site.

Does winvnc.exe start manual from cmd ?

Is it a problem after reboot or does the service also fail when you start the service manual.
in a cmd
net start uvnc_service

In the windows event manager you normal should find some reason for a service stop

More info needed.

[Chesser]

Two accounts have been created on computers: User and Administrator.
For the user, the command line has always been blocked.
If you start the service as administrator "net start uvnc_service", then the service starts and runs.
If you start the uvnc-server manually, then everything also starts working.
If you restart your computer after starting the service or uvnc-server, then everything also works.
BUT if the computer is turned off and then turned on again, the service will not start. Nothing was found in the logs, as if there was no such service. However, it is there with automatic start, but it does not start after being turned on.

[Rudi De Vos]

chesser,

restart = reboot
trun off and on = sleep and resume ??
If the service think a sleep is a shutdown then he close, there was a change to prevent the server to restart on shutdown...could it be this.
This take some time to investigate

Try this as workaround.