UltraVNC

Hi redge,

Actually before I posted here, I already had a long discussion with Karl Runge, the owner of ssvnc, x11vnc and libvncserver project, regarding this topic. The discussion started with whether to add MSLogon client-side support, and Karl pointed straight towards this 31 bit security issue ...

Hi,

Yes, crash is of course not acceptable, but this is really an arithmetic overflow problem in the old 31bit code, not the patched new one. And unfortunately I don't see any possibility to for the server check if the client supports only 31bit or not.

Now I can see two options for us, correctly ...

This patch will upgrade MSLogon to use 63 bits. I gave up 1 bit in order to avoid massive changing.

Test result:
o New viewer can connect to new server and old server without any problem.
o Old viewer will crash when connect to new server.


Index: UltraVNC Project Root/UltraVNC/rfb/dh.h ...

Talking about compatibility, using new viewer to connect to old server shouldn't be any problem. it's just the problem when using an old viewer to connect to a new server.

I think backward compatibility can be maintained only if you keep the generator (the X in DH::XpowYmodN) at 31 bit, but this will probably decrease the security strength and a little more difficult to maintain.

My suggestion is to let user use a newer viewer if they are going to use the newer ...

Hi,

I think most people already aware that the current MSLogon only use 31bit key size for DH key exchange. This is extremely unsecure and scaring people using it.

Recently I checked the source codes and it turned out that in dh.c, the program calculating x^y%m is not good and causing this 31bit ...