Как это не сказал?во втором моем сообщении - vino - 2.28.2-0
Weak Authentication
VNC uses a simple and weak DES based challenge-response authentication scheme. See
here for more details. With Vino as it stands,
I would feel safer not setting any password at all and approving each connection manually as it comes in.Ideally we should properly authenticate any user which wishes to connect using PAM just like SSH or whatever.
...
VNC uses a simple DES based challenge-response authentication scheme. In order to authenticate the client, the server sends a random 16 byte challenge and the client then encrypts the challenge with DES using the user supplied password as a key. If the response matches the expected result, the client is authenticated. Otherwise, the server closes the connection. There are a number of possible vulnerabilities with this mechanism.
Firstly, the password, being limited to 8 characters, could be brute force guessed by an attacker who continually tries to authenticate using different passwords[21]. The standard way of making such attacks unfeasible is to enforce a delay between failed authentication attempts - i.e. if there has been a failed authentication attempt, delay sending the challenge to the next client who connects for a number of seconds.
Another possible vulnerability is the predictability of the random challenge sent by the server. If the server, under any circumstances, sends a challenge which has previously been used in a successful authentication attempt there is the possibility that an attacker may use the previously observered valid response again. An example[22] of such is if the server re-seeds the random number generator used to produce the challenge with the current time on each connection attempt. In this case, if an attacker connects to the VNC server within the same one second window as a valid client, then the attacker will receive the same challenge as the valid client and use the response from that client to authenticate. To avoid such a vulnerability the server should produce highly unpredictable challenges using the cryptographically strong random number generator providied with the GNU TLS library.
Challenge-response authentication schemes are inherently susceptible to man-in-the-middle attacks. The basic idea is that attacker uses a client to generate a valid response for a given challenge. One way[23] of carrying out such an attack is if the attack can intercept and modify the packets flowing between the client and the server. The attacker can then replace the challenge from the server with a challenge the attacker has received in a pending authentication attempt. The client then returns a valid response for that challenge with which the attacker can use to complete its authentication.