Re: [Tigervnc-devel] vncviewer password prompt text mode instead of window

2011-05-05 Thread Pierre Ossman
On Wed, 4 May 2011 21:57:44 +
Cook, Jason jason.c...@wesd.org wrote:

 This question has been asked before in 2009:
 
 Jeff Kowalczyk
 Thu, 17 Sep 2009 14:20:27 -0700⁠
 
 (Begin quote)
 
 Tightvnc-1.3.10 prompted for a password in the terminal from which it was
 started. When using a -via ssh tunnel, both password prompts conveniently
 occurred in the same terminal.
 
 Now that I have switched to tigervnc-1.0, it raises a password prompt window
 in X.
 
 Can we have an option to use the terminal password prompt?
 
 (End quote)
 
 I second this request. The current X based prompt is not keyboard accessible. 
 It forces a user to click in the input box before typing the password.
 
 If directing the password prompt back to the terminal is not technically 
 feasible, is it possible to have the X input automatically selected without 
 requiring a mouse click? This would provide a similar convenience.

The new viewer I'm writing should have better focus behaviour, but
asking on stdin/stdout should also be possible. Easiest way is probably
by adding another option for this behaviour.

I'm afraid I don't have any time to look at this issue now, but please
file a bug in the tracker so that this request doesn't get lost.

Rgds
-- 
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


signature.asc
Description: PGP signature
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] potential vulnerability in TLS secType?

2011-05-05 Thread Adam Tkac
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 int).

Regards, Adam

On 05/05/2011 08:43 AM, Martin Koegler wrote:
 On Wed, May 04, 2011 at 10:51:06PM -0400, Brian Hinz wrote:
 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
 prompted for a username and password (meaning the client is processing phase
 2 of the security stack) before the certificate has been verified.  I
 noticed this while testing a known bad certificate - presumably this means
 that the username  password are sent in the clear since the TLS handshake
 never completes.
 Thanks for spotting this. The server should send 0, if he can't start the 
 handshake - so it
 is still possible to sent the error messages back to the client.

 The problem is, that a malicus server could send 0 and then authentification
 succeded. It is caused by the fact, the I reused the common code for returing 
 the
 error message.

 A solution can be, that the error fetching code from 
 CConnection::processSecurityResultMsg
 is inlined in CSecurityTLS::processMsg, like the following (untested):

 diff --git a/common/rfb/CSecurityTLS.cxx b/common/rfb/CSecurityTLS.cxx
 index 6028792..17ed93c 100644
 --- a/common/rfb/CSecurityTLS.cxx
 +++ b/common/rfb/CSecurityTLS.cxx
 @@ -171,8 +171,15 @@ bool CSecurityTLS::processMsg(CConnection* cc)
  if (!is-checkNoWait(1))
return false;
  
 -if (is-readU8() == 0)
 -  return true;
 +if (is-readU8() == 0) {
 +  int result = is-readU32();
 +  CharArray reason;
 +  if (result == secResultFailed || result == secResultTooMany)
 +reason.buf = is-readString();
 +  else
 +reason.buf = strDup(Authentication failure (protocol error));
 +  throw AuthFailureException(reason.buf);
 +}
  
  if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
throw AuthFailureException(gnutls_init failed);

Index: common/rfb/CSecurityTLS.cxx
===
--- common/rfb/CSecurityTLS.cxx (revision 4399)
+++ common/rfb/CSecurityTLS.cxx (working copy)
@@ -171,8 +171,15 @@
 if (!is-checkNoWait(1))
   return false;
 
-if (is-readU8() == 0)
-  return true;
+if (is-readU8() == 0) {
+  rdr::U32 result = is-readU32();
+  CharArray reason;
+  if (result == secResultFailed || result == secResultTooMany)
+reason.buf = is-readString();
+  else
+reason.buf = strDup(Authentication failure (protocol error));
+  throw AuthFailureException(reason.buf);
+}
 
 if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
   throw AuthFailureException(gnutls_init failed);
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] [ tigervnc-Feature Request Tracker-3297845 ] vncviewer multiple fullscreen

2011-05-05 Thread SourceForge.net
Feature Request Tracker item #3297845, was opened at 2011-05-05 12:38
Message generated for change (Tracker Item Submitted) made by timtatanka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1126849aid=3297845group_id=254363

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows version
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: tatanka (timtatanka)
Assigned to: Peter Åstrand (astrand)
Summary: vncviewer multiple fullscreen

Initial Comment:
An option to let the windows vncviewer be used in fullscreen mode over 
multiple/all screens. Now the viewer is only able to be in fullscreen mode on 1 
of the screens.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1126849aid=3297845group_id=254363

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] potential vulnerability in TLS secType?

2011-05-05 Thread Brian Hinz
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
--- rfb.unix/CSecurityTLS.cxx 2011-05-05 06:55:24.826533250 -0400
***
*** 168,182 
initGlobal();

if (!session) {
  if (!is-checkNoWait(1))
return false;

- if (is-readU8() == 0)
-   return true;
-
  if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
throw AuthFailureException(gnutls_init failed);

  if (gnutls_set_default_priority(session) != GNUTLS_E_SUCCESS)
throw AuthFailureException(gnutls_set_default_priority failed);

--- 168,179 
***
*** 197,208 
--- 194,208 
if (err != GNUTLS_E_SUCCESS) {
  vlog.error(TLS Handshake failed: %s\n, gnutls_strerror (err));
  shutdown(false);
  throw AuthFailureException(TLS Handshake failed);
}

+ if (is-readU8() == 0)
+   return true;
+
checkSession();

cc-setStreams(fis = new rdr::TLSInStream(is, session),
   fos = new rdr::TLSOutStream(os, session));

return true;


On Thu, May 5, 2011 at 2:43 AM, Martin Koegler
mkoeg...@auto.tuwien.ac.atwrote:

 On Wed, May 04, 2011 at 10:51:06PM -0400, Brian Hinz wrote:
  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
  prompted for a username and password (meaning the client is processing
 phase
  2 of the security stack) before the certificate has been verified.  I
  noticed this while testing a known bad certificate - presumably this
 means
  that the username  password are sent in the clear since the TLS
 handshake
  never completes.

 Thanks for spotting this. The server should send 0, if he can't start the
 handshake - so it
 is still possible to sent the error messages back to the client.

 The problem is, that a malicus server could send 0 and then
 authentification
 succeded. It is caused by the fact, the I reused the common code for
 returing the
 error message.

 A solution can be, that the error fetching code from
 CConnection::processSecurityResultMsg
 is inlined in CSecurityTLS::processMsg, like the following (untested):

 diff --git a/common/rfb/CSecurityTLS.cxx b/common/rfb/CSecurityTLS.cxx
 index 6028792..17ed93c 100644
 --- a/common/rfb/CSecurityTLS.cxx
 +++ b/common/rfb/CSecurityTLS.cxx
 @@ -171,8 +171,15 @@ bool CSecurityTLS::processMsg(CConnection* cc)
 if (!is-checkNoWait(1))
   return false;

 -if (is-readU8() == 0)
 -  return true;
 +if (is-readU8() == 0) {
 +  int result = is-readU32();
 +  CharArray reason;
 +  if (result == secResultFailed || result == secResultTooMany)
 +reason.buf = is-readString();
 +  else
 +reason.buf = strDup(Authentication failure (protocol error));
 +  throw AuthFailureException(reason.buf);
 +}

 if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
   throw AuthFailureException(gnutls_init failed);

 Regards,
 Martin Kögler



 --
 WhatsUp Gold - Download Free Network Management Software
 The most intuitive, comprehensive, and cost-effective network
 management toolset available today.  Delivers lowest initial
 acquisition cost and overall TCO of any competing solution.
 http://p.sf.net/sfu/whatsupgold-sd
 ___
 Tigervnc-devel mailing list
 Tigervnc-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] potential vulnerability in TLS secType?

2011-05-05 Thread Brian Hinz
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.

 Can you please test if attached patch solves this issue? It is Martin's
 patch with little modification (result is rdr::U32 instead of int).

 Regards, Adam

 On 05/05/2011 08:43 AM, Martin Koegler wrote:
  On Wed, May 04, 2011 at 10:51:06PM -0400, Brian Hinz wrote:
  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
  prompted for a username and password (meaning the client is processing
 phase
  2 of the security stack) before the certificate has been verified.  I
  noticed this while testing a known bad certificate - presumably this
 means
  that the username  password are sent in the clear since the TLS
 handshake
  never completes.
  Thanks for spotting this. The server should send 0, if he can't start the
 handshake - so it
  is still possible to sent the error messages back to the client.
 
  The problem is, that a malicus server could send 0 and then
 authentification
  succeded. It is caused by the fact, the I reused the common code for
 returing the
  error message.
 
  A solution can be, that the error fetching code from
 CConnection::processSecurityResultMsg
  is inlined in CSecurityTLS::processMsg, like the following (untested):
 
  diff --git a/common/rfb/CSecurityTLS.cxx b/common/rfb/CSecurityTLS.cxx
  index 6028792..17ed93c 100644
  --- a/common/rfb/CSecurityTLS.cxx
  +++ b/common/rfb/CSecurityTLS.cxx
  @@ -171,8 +171,15 @@ bool CSecurityTLS::processMsg(CConnection* cc)
   if (!is-checkNoWait(1))
 return false;
 
  -if (is-readU8() == 0)
  -  return true;
  +if (is-readU8() == 0) {
  +  int result = is-readU32();
  +  CharArray reason;
  +  if (result == secResultFailed || result == secResultTooMany)
  +reason.buf = is-readString();
  +  else
  +reason.buf = strDup(Authentication failure (protocol error));
  +  throw AuthFailureException(reason.buf);
  +}
 
   if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
 throw AuthFailureException(gnutls_init failed);
 

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


Re: [Tigervnc-devel] potential vulnerability in TLS secType?

2011-05-05 Thread Martin Koegler
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
 *** rfb.unix/CSecurityTLS.cxx.bak 2011-05-05 06:54:11.018963720 -0400
 --- rfb.unix/CSecurityTLS.cxx 2011-05-05 06:55:24.826533250 -0400
 ***
 *** 168,182 
 initGlobal();
 
 if (!session) {
   if (!is-checkNoWait(1))
 return false;
 
 - if (is-readU8() == 0)
 -   return true;
 -
   if (gnutls_init(session, GNUTLS_CLIENT) != GNUTLS_E_SUCCESS)
 throw AuthFailureException(gnutls_init failed);
 
   if (gnutls_set_default_priority(session) != GNUTLS_E_SUCCESS)
 throw AuthFailureException(gnutls_set_default_priority failed);
 
 --- 168,179 
 ***
 *** 197,208 
 --- 194,208 
 if (err != GNUTLS_E_SUCCESS) {
   vlog.error(TLS Handshake failed: %s\n, gnutls_strerror (err));
   shutdown(false);
   throw AuthFailureException(TLS Handshake failed);
 }
 
 + if (is-readU8() == 0)
 +   return true;
 +
 checkSession();
 
 cc-setStreams(fis = new rdr::TLSInStream(is, session),
fos = new rdr::TLSOutStream(os, session));
 
 return true;

The readU8 is a flag to signal by the server to the client, that
it can't start the handshake and therefore has to sent the error as plaintext 
back
(eg because it can't read the certificate).

Your are proposing a different protocol, which don't allow to return an error 
message before the handshake completed.

Regards,
Martin K?gler


--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] Report on TigerVNC autorepeat issue.

2011-05-05 Thread Robert Goley


  
  
I have finally tested DRC's new build. The autorepeat functionality
is working now from a windows client to a linux server. It does
seem to take a bit longer for the second character to kick in but I
have been working without autorepeat in VI for so long now that it
is a very welcome fix. Thats for getting this issue resolved.


-- 
  Robert Goley

FOSS
  Implementation Specialist
  Toll Free: (800) 338-4984
  Local: (770) 479-7933
  Fax: (770) 479-4076
  www.openrda.com

America's only Free  Open Source
fund accounting software company. 

  

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] [ tigervnc-Bug Tracker-3297994 ] password focus behaviour

2011-05-05 Thread SourceForge.net
Bug Tracker item #3297994, was opened at 2011-05-05 10:31
Message generated for change (Tracker Item Submitted) made by cookja
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1126848aid=3297994group_id=254363

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UN*X version
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: derelict (cookja)
Assigned to: Adam Tkac (atkac)
Summary: password focus behaviour

Initial Comment:
The password prompt is not keyboard accessible. It forces a user to click in 
the input box before typing the password. Correct behavior would be that the 
input field of the prompt window is automatically selected and that the TAB 
key toggles between fields.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1126848aid=3297994group_id=254363

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


[Tigervnc-devel] [ tigervnc-Feature Request Tracker-3297998 ] password prompt on stdin/stdout

2011-05-05 Thread SourceForge.net
Feature Request Tracker item #3297998, was opened at 2011-05-05 10:44
Message generated for change (Tracker Item Submitted) made by cookja
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1126849aid=3297998group_id=254363

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UN*X version
Group: trunk
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: derelict (cookja)
Assigned to: Adam Tkac (atkac)
Summary: password prompt on stdin/stdout

Initial Comment:
Option to prompt for password on the same terminal from which it was launched.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=1126849aid=3297998group_id=254363

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel