Community
Participate
Working Groups
Tested on Linux gtk2 and Mac OS X and 10.2 Carbon - Iall other versions are vulnerable as they use shared codebase and is implementation. Description of the problem: Eclipse ships with a pure java based ssh1 client for use with cvs. This is enabled by selecting extssh as the method of authentication to a cvs repository. The client supplied is an SSH1 client and only supports password authentication - users can use standard ext method for public key authentication with a suitable ssh-agent (pagent, openssh, etc). However when using the Eclipse extssh component no history of host keys is kept. This enables an attacker who can poison the name resolution of the eclipse client to potentially steal passwords through a modified ssh daemon on a server under there control. Steps to Reproduce: 1. Set up access to an external cvs repository with extssh and a password. (preferably with a username that doesn't exist locally eg - notme). Close eclipse. 2. Edit /etc/hosts to point to another ssh server (eg localhost) 3. Open eclipse and choose to browse the repository from the cvs perspective. 4. In your auth logs you should get messages like: sshd[1234]: Failed none for illegal user notme from xxx.xxx.xxx.xxx port xxxx sshd[1234]: Failed password for illegal user notme from xxx.xxx.xxx.xxx port xxxx In your log (/var/log/auth.log in the case of Mandrake) Expected results: Should get a prompt saying key changed. A malicious user could gain access to valuable accounts Workaround: Use an ssh2 client with public keys with the ext method.
Created attachment 1924 [details] Initial work to check keys
The attachment above is incorrect. It throws an array out of bounds exception. The following patch corrects it - currently I'm forcing an IOException untill I can get the format of the fingerprint ala the SSH 1.5 protocol (openssh style).
Created attachment 1948 [details] Updated patch file
Apologies again - old file got uploaded. Ignore previous patches, fixed and sorted out minor whitespace differences this time as well.
Created attachment 1949 [details] Updated patch *IGNORE FIRST TWO*
I've done some more work, tested the fingerprint is identical to OpenSSH and gone some way to storing state. A patch will follow
Created attachment 2050 [details] Refactored initial work to maintain state of known hosts
Created attachment 2300 [details] Patch working with native known_hosts
This patch will also work with Eclipse on OS X, but doesn't check for it.
Created attachment 2301 [details] Same patch without depending on 1.4 features
Created attachment 2302 [details] Real version
Fix released to HEAD
Well, I'm not familiar with OS X. The problem is that the real question to ask when determining the location of known_hosts would be: "do we have a native ssh installation on this platform", with the answer presumably yes for unix and unix-like ones. Unfortunately, Core does not give us an API to ask whether the platform is unix-like.
