Hello Brian,
thanks for your feedback, I committed (r4400 and r4401) Martin's patch
with my modification.
Thanks for your report!
Regards, Adam
On 05/05/2011 01:27 PM, Brian Hinz wrote:
Adam,
Martin's patch seems to work (my suggestion did not).
-brian
On Thu, May 5, 2011 at 5:45 AM,
Hello Brian,
thanks for notification about this issue, you are right that password
might been sent over network without proper validation of the X.509 certs.
Can you please test if attached patch solves this issue? It is Martin's
patch with little modification (result is rdr::U32 instead of
Wouldn't this (also untested) work as well, and have the advantage of
relying on gnutls to verify that the handshake was completed?
diff -Nr -C 6 rfb.unix/CSecurityTLS.cxx.bak rfb.unix/CSecurityTLS.cxx
*** rfb.unix/CSecurityTLS.cxx.bak 2011-05-05 06:54:11.018963720 -0400
---
Adam,
Martin's patch seems to work (my suggestion did not).
-brian
On Thu, May 5, 2011 at 5:45 AM, Adam Tkac at...@redhat.com wrote:
Hello Brian,
thanks for notification about this issue, you are right that password
might been sent over network without proper validation of the X.509 certs.
On Thu, May 05, 2011 at 07:01:49AM -0400, Brian Hinz wrote:
Wouldn't this (also untested) work as well, and have the advantage of
relying on gnutls to verify that the handshake was completed?
diff -Nr -C 6 rfb.unix/CSecurityTLS.cxx.bak rfb.unix/CSecurityTLS.cxx
***
Hi,
I think that I just stumbled onto a possible security vulnerability in
CSecurityTLS. It seems as though CSecurityTLS::processMsg returns true
before the handshake has completed (possibly due to the if (is.readU8() ==
0) test on line 174). In the case of secTypes like x509plain, the user is
