Bugtraq mailing list archives
Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta
From: Russell Harding <hardingr () ucsub colorado edu>
Date: Sat, 27 Jul 2002 19:32:48 -0600 (MDT)
<comments below> On Fri, 26 Jul 2002, Bela Lubkin wrote:
Burton M. Strauss III wrote:You know, that's only partially a solution. For those of us who haven't chosen to PAY for the upgrade to 3.4, we're left out in the cold. Quoting from VanDyke's web page: "All users may evaluate SecureCRT 3.4 for 30 days free of charge. Registered users who purchased licenses before July 1, 2000 should consult the Upgrade Eligibility page to learn about licensing the 3.4 upgrade." and "SecureCRT Upgrade Registered users who purchased licenses before July 1, 2001 may choose to purchase SecureCRT upgrades starting at $39.95 for a single copy. <snip /> SecureCRT users who purchased licenses between January 1 and July 1, 2000 are eligible to download SecureCRT 3.3.3 and upgrade without charge. SecureCRT users who purchased licenses before January 1, 2000 are eligible to download SecureCRT 3.2.1 and upgrade without charge." I'm not unsympathetic to the need to have a licensing revenue stream, but let's remember that this leaves (dozens? hundreds? thousands? Just me) of your customers unprotected.One of the README files on their site (I read it earlier today and didn't note the URL) says that a patched 3.2.1 version will be made available shortly. They are not leaving you out in the cold. You just need to wait a couple of days before resuming your practice of ssh'ing in to untrusted sites. (BTW, if sshd on a site might be a corrupted, malicious trojan which injects code into your local ssh client -- might it not also be a corrupted, malicious trojan which records encrypted password information, passes on a decrypted stream of everything you type in a session, or who knows what else? If you do not trust the sshd to which you are connecting, I'm not sure it makes very much difference whether the client has code-injection portholes or not...)Bela<
Of course it matters if the client has code-injection 'portholes' as you call them. Someone may be using nasty tricks through ARP, DNS, or even manipulating routing tables, such that you are not actually connecting to a host you trust. This is why ssh implements host keys, so you can verify the authenticicy of the remote host. However, in the case described above, with SecureCRT, your machine would already be compromised before host key verification took place. -Russell Harding
Current thread:
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta kelli burkinshaw (Jul 23)
- <Possible follow-ups>
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta kelli burkinshaw (Jul 25)
- RE: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Burton M. Strauss III (Jul 26)
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Bela Lubkin (Jul 27)
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Bela Lubkin (Jul 28)
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Russell Harding (Jul 28)
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Bela Lubkin (Jul 28)
- Re: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Jim Paris (Jul 29)
- RE: Arbitrary Code Execution Vulnerability in VanDyke SecureCRT 3.4 & 4.0 beta Burton M. Strauss III (Jul 26)