File Transfer support for rfbUltraVNC_MsLogonIIAuth

[wqweto]

In ClientConnection::NegotiateProtocolVersion function (in ClientConnection.cpp file) for protocol version RFB 003.008 there is a comment left like this

else if (m_minorVersion == 8) // adzm 2010-09 - RFB 3.8
{
	// adzm2010-10 - RFB3.8 - m_fServerKnowsFileTransfer set during rfbUltraVNC auth
}

But in ClientConnection::AuthenticateServer function the mentioned flag m_fServerKnowsFileTransfer = true is set only for rfbUltraVNC (no password) security type and not for any other password protected security type under rfbUltraVNC_Xxx family incl. rfbUltraVNC_MsLogonIIAuth (which is the exact reason I'm posting this issue).

This prevents protocol version RFB 003.008 servers from being recognized by the client as supporting UltraVNC's proprietary File Transfer sub-protocol when the server is password protected but allows it just ok when the server is not password protected. . . which is somewhat weird behavior.

Is this a deliberate omission or do you want me to send a PR with the m_fServerKnowsFileTransfer = true set for all rfbUltraVNC_Xxx family of authentication (or rfbUltraVNC_MsLogonIIAuth only)?

What else can I do in my RFB 003.008 server to enable File Transfer for password protected instances?

p.s. My incomplete VNC server effort is here.

[RudiDeVos]

The authentication is a vector.

  | [0] | 17 '\x11' | unsigned char // rfbUltraVNC 17
  | [1] | 115 's' | unsigned char // rfbUltraVNC_SecureVNCPluginAuth_new 0x73
  | [2] | 114 'r' | unsigned char // rfbUltraVNC_SecureVNCPluginAuth 0x72

As encoding 17 is part of the vector m_fServerKnowsFileTransfer = true

[wqweto]

Is there a reason the file transfer protocol extension is not enabled when server offers (and UltraVNC viewer accepts) rfbUltraVNC_MsLogonIIAuth authentication?

Note that file transfer protocol extension is enabled for passwordless rfbUltraVNC authentication only but both rfbUltraVNC and rfbUltraVNC_MsLogonIIAuth security types are implemented by UltraVNC only.

It seems weird that when rfbUltraVNC_MsLogonIIAuth is used the viewer does not allow file transfers but with passwordless rfbUltraVNC file transfer protocol extension is activated just ok.

[RudiDeVos]

The authentication is a vector and authentications are combined.
A) {rfbUltraVNC , rfbUltraVNC_SecureVNCPluginAuth_new , rfbUltraVNC_SecureVNCPluginAuth }
OR
B) {rfbUltraVNC , rfbUltraVNC_MsLogonIIAuth }
C) {rfbUltraVNC_MsLogonIIAuth }

A) rfbUltraVNC is handled ( set filetransfer true) and request next authentication.
rfbUltraVNC_SecureVNCPluginAuth_new is handled result can be allow/disallow/nothandled
In case not handled we use the next rfbUltraVNC_SecureVNCPluginAuth this has allow/disallow

B) rfbUltraVNC is handled ( set filetransfer true) and request next authentication.
rfbUltraVNC_MsLogonIIAuth is used for authentication.

C) rfbUltraVNC_MsLogonIIAuth is used, but you don't indicate the sever support the UltraVNC options.
Someone can implement rfbUltraVNC_MsLogonIIAuth without implemeneting the Filetransfer.
Usual it would be send as {rfbMYVNCVersion, rfbUltraVNC_MsLogonIIAuth }

[wqweto]

What is rfbMYVNCVersion? I cannot find this constant in the sources.

Ok, so what should a VNC server send as supported security types to use password-protected rfbUltraVNC_MsLogonIIAuth and indicate support for file transfer protocol extension?

If my server signals both rfbUltraVNC and rfbUltraVNC_MsLogonIIAuth security types being available UltraVNC viewer always uses passwordless rfbUltraVNC and never asks for password. If only rfbUltraVNC_MsLogonIIAuth is signalled being available the viewer asks for password but does not allow file transfer protocol extension.

Someone can implement rfbUltraVNC_MsLogonIIAuth without implemeneting the Filetransfer

Is this a problem? I though UltraVNC viewer always first sends AbortFileTransfer message to negotiate file transfer availability with the server anyway.

[RudiDeVos]

 What is rfbMYVNCVersion? I cannot find this constant in the sources.
rfbMYVNCVersion was just a sample, like RfbUltravnc there exist many others.

Ok, so what should a VNC server send as supported security types to use password-protected rfbUltraVNC_MsLogonIIAuth and indicate support for file transfer protocol extension?
The authentication vector contain.
  | [0] | 17 '\x11' | unsigned char
  | [1] | 113 'q' | unsigned char
{rfbUltraVNC , rfbUltraVNC_MsLogonIIAuth }

If my server signals both rfbUltraVNC and rfbUltraVNC_MsLogonIIAuth security types being available UltraVNC viewer always uses passwordless rfbUltraVNC and never asks for password. If only rfbUltraVNC_MsLogonIIAuth is signalled being available the viewer asks for password but does not allow file transfer protocol extension.

Then you need to loop true the authentications. The problem is that your viewer doesn't handle the next authentication

case rfbUltraVNC:
set options for ultravnc
move to next authentication in the vector
Then you handle the next rfbUltraVNC_MsLogonIIAuth

The viewer is compatible with tiger/tight and realVNC, when rfbUltraVNC is not set, we don't use any part of the FileTransfer.

Is this a problem? I though UltraVNC viewer always first sends AbortFileTransfer message to negotiate file transfer availability with the server anyway.
Only Ultravnc servers/viewers negiotiate the supported filetransfer mode.
You can mix old and new ultravnc viewers servers. To support the old UltraVNC FT version we negotiate it first.

[wqweto]

Then you need to loop true the authentications. The problem is that your viewer doesn't handle the next authentication

I'm writing a server (not a viewer) and the problem I have is when using UltraVNC viewer as mentioned in the first post. It is the UltraVNC viewer that does not set it's internal m_fServerKnowsFileTransfer flag when your proprietary rfbUltraVNC_MsLogonIIAuth authentication is negotiated to be used between the server and the viewer.

In my server I successfully implemented rfbUltraVNC_MsLogonIIAuth by first using 64-bit Diffie-Hellman key exchange to come up with common shared secret and then using this shared secret to encrypt the password using DES in CBC mode -- all of this I had to deduce by reading UltraVNC sources as it's not documented and it works very well with your UltraVNC viewer. So I have a working rfbUltraVNC_MsLogonIIAuth implemented between my VNC server and your UltraVNC viewer. (Not sure if there is any other non-UltraVNC server that does this.)

The problem is that in rfbUltraVNC_MsLogonIIAuth security type the viewer does not enable UltraVNC proprietary file transfer protocol extension which I also successfully reverse engineered from UltraVNC sources but can only enable it with the passwordless rfbUltraVNC authentication. When using rfbUltraVNC security type the viewer sets its internal m_fServerKnowsFileTransfer to enable file transfer protocol extension and my VNC server and your UltraVNC viewer can transfer files in both directions and everything works very well. (Not sure if there is any other non-UltraVNC server that does this too.)

Do you understand my problem with rfbUltraVNC_MsLogonIIAuth security type or do you want me to send a Pull Request with the exact fix to enable file transfer protocol extension when your viewer is using this security type? It's a single line with m_fServerKnowsFileTransfer = true actually.

[RudiDeVos]

My mistake, you are building the server.
Then it's your server code that require changes.

The AuthenticateClient(std::vector& current_auth) call himself back with a smaller list.
You need to send something like this on the server, code is complex, but extracte it look like this
for {rfbUltraVNC, rfbUltraVNC_MsLogonIIAuth}

unsigned char authCount  = 2;
Send((const char*)&authCount, 1)
authType = rfbUltraVNC
Send((const char*)&authType, 1)
authType = rfbUltraVNC_MsLogonIIAuth
Send((const char*)&authType, 1)

Read(auth_accepted,1)
if (auth_accepted == rfbUltraVNC) {
     SetUltraViewer(true);
     auth_result = rfbVncAuthContinue
     Send((const char*)&auth_result , 1)
}


unsigned char authCount  = 1;
Send((const char*)&authCount, 1)
authType = rfbUltraVNC_MsLogonIIAuth
Send((const char*)&authType, 1)
Read(auth_accepted,1)
if (auth_accepted == rfbUltraVNC_MsLogonIIAuth) {
AuthMsLogon()
}

[wqweto]

Thank you very much! That did the trick and I have the file transfer protocol extension working in the UltraVNC viewer since commit wqweto/VbVncServer@ba3b5ea

On first pass the server sends a single rfbUltraVNC only (no rfbUltraVNC_MsLogonIIAuth yet) and only if the viewer chooses to use it as the security type for the session and only if the server is password-protected, only then is a second pass retried (returning rfbVncAuthContinue result) by sending the list of security types second time with a single rfbUltraVNC_MsLogonIIAuth option available.

Now this is a one convoluted security type negotiation it has become but I guess this is what it has become thanks to the organic growth of the VNC protocol through the years. Thank you again!

[wqweto]

At some point I realised that the two pass negotiation allows for rfbUltraVNC on first pass and standard rfbVncAuth on second which drops rfbUltraVNC_MsLogonIIAuth implementation altogether and shaves ~200 LOC off my minimal VNC server which is nice!

I'll be closing this now.

[wqweto]

Another issue with using a rfbUltraVNC on first pass just to set m_fServerKnowsFileTransfer before continuing with another supported authentication is that this flag is passed way earlier to CreateButtons function for the toolbar to include extra buttons for file transfer and other known UltraVNC server specific functions.

The problem is that when m_fServerKnowsFileTransfer is set for rfbUltraVNC authentication the toolbar is already created without the extra buttons and there is no call to extend it with file transfer button and others. This way the viewer ends up with no button for file transfer on the toolbar but with File Transfer... option in system menu still magically working. But there is no Switch Desktop option in the system menu so this action is only accessible through its button on the extended toolbar which unfortunate is not available in my use-case.

[wqweto]

Just tested with UltraVNC Viewer 1.4.2.0 and the issue with extended toolbar seems fixed.

Closing this.