From cthomas at Soneticom.com Sat Jul 1 00:56:48 2006 From: cthomas at Soneticom.com (Clint Thomas) Date: Fri, 30 Jun 2006 12:56:48 -0400 Subject: Dropbear or SSH on Busybox In-Reply-To: <200606292030.22275.rob@landley.net> Message-ID: <3C02138692C13C4BB675FE7EA240952913285A@bluefin.Soneticom.local> I compile the dropbearmulti binary on my main machine, using powerpc-linux cross compilers. After it has been compiled, I Load it onto my target via ftp, and try to execute it. At first, it returns an error of "permission denied", so I chmod 777 the binary so I can execute it. When I try to execute after this, I get the error /lib/libc.so.6: version `GLIBC_2.3' not found When I check the version of /lib/libc.so.6, it returns that it is version 2.2.1, with several available extensions. How would I go about statically linking it? Clint -----Original Message----- From: Rob Landley [mailto:rob at landley.net] Sent: Thursday, June 29, 2006 8:30 PM To: dropbear at ucc.asn.au Cc: Clint Thomas Subject: Re: Dropbear or SSH on Busybox On Thursday 29 June 2006 5:07 pm, Clint Thomas wrote: > Hey, > > I am running a dev board based around the 8555E powerpc processor, > running an embedded version of linux with glibc version 2.2.3, kernel > 2.4.27, and busybox version .52. I am trying to figure out if there is > any way to setup SSH on this machine without updating the glibc > libraries, the kernel or busybox. The telnet server is having a hard > time connnecting, and I would much rather be using SSH to remote > connect into this machine. Is there any way for dropbear to run > without glibc version 2.3 or higher? Perhaps an older version ? A) You don't have to update busybox. It's unrelated. B) What error do you get when you try to build it against the old glibc? C) You could always statically link it against a current uClibc. Rob -- Never bet against the cheap plastic solution. From erik at hovland.org Sat Jul 1 02:35:01 2006 From: erik at hovland.org (Erik Hovland) Date: Fri, 30 Jun 2006 11:35:01 -0700 Subject: monotone and dropbear Message-ID: <20060630183501.GA8686@mage.jpl.nasa.gov> I have been trying to use this post to get to the dropbear monotone repo: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q3/000244.html But I get a: monotone: connecting to monotone.ucc.asn.au monotone: network error: failed to connect: Connection refused Do you have new directions or new servers to get public access to the dropbear repo? What version of monotone is required (I am using 0.25)? Thanks E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request From matt at ucc.asn.au Sat Jul 1 11:02:03 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 1 Jul 2006 11:02:03 +0800 Subject: monotone and dropbear In-Reply-To: <20060630183501.GA8686@mage.jpl.nasa.gov> References: <20060630183501.GA8686@mage.jpl.nasa.gov> Message-ID: <20060701030203.GI12898@ucc.gu.uwa.edu.au> On Fri, Jun 30, 2006 at 11:35:01AM -0700, Erik Hovland wrote: > I have been trying to use this post to get to the dropbear monotone > repo: > http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2005q3/000244.html > > But I get a: > monotone: connecting to monotone.ucc.asn.au > monotone: network error: failed to connect: Connection refused > > Do you have new directions or new servers to get public access to the > dropbear repo? What version of monotone is required (I am using 0.25)? You'll need to be using 0.26 or 0.27, mtn pull monotone.ucc.asn.au au.asn.ucc.matt.dropbear should work. The port number changed between 0.25 and 0.26. Cheers, Matt From erik at hovland.org Thu Jul 6 06:33:14 2006 From: erik at hovland.org (Erik Hovland) Date: Wed, 5 Jul 2006 15:33:14 -0700 Subject: [patch] remove deadcode Message-ID: <20060705223314.GF18957@mage.jpl.nasa.gov> This patch removes an #if 0 set of code. And it removes a passphrase check which cannot happen. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "keyimport.c" # from [4d6aa56819151b18d6828b1a9b1db0b9864e40b3] # to [4052ebe94ea2b063028c4cd9f437cbd5180a9e54] # ============================================================ --- keyimport.c 4d6aa56819151b18d6828b1a9b1db0b9864e40b3 +++ keyimport.c 4052ebe94ea2b063028c4cd9f437cbd5180a9e54 @@ -926,40 +926,6 @@ if (passphrase) { fprintf(stderr, "Encrypted keys aren't supported currently\n"); goto error; -#if 0 - /* - * Invent an iv. Then derive encryption key from passphrase - * and iv/salt: - * - * - let block A equal MD5(passphrase || iv) - * - let block B equal MD5(A || passphrase || iv) - * - block C would be MD5(B || passphrase || iv) and so on - * - encryption key is the first N bytes of A || B - */ - struct MD5Context md5c; - unsigned char keybuf[32]; - - for (i = 0; i < 8; i++) iv[i] = random_byte(); - - MD5Init(&md5c); - MD5Update(&md5c, (unsigned char *)passphrase, strlen(passphrase)); - MD5Update(&md5c, iv, 8); - MD5Final(keybuf, &md5c); - - MD5Init(&md5c); - MD5Update(&md5c, keybuf, 16); - MD5Update(&md5c, (unsigned char *)passphrase, strlen(passphrase)); - MD5Update(&md5c, iv, 8); - MD5Final(keybuf+16, &md5c); - - /* - * Now encrypt the key blob. - */ - des3_encrypt_pubkey_ossh(keybuf, iv, outblob, outlen); - - memset(&md5c, 0, sizeof(md5c)); - memset(keybuf, 0, sizeof(keybuf)); -#endif } /* @@ -976,12 +942,6 @@ goto error; } fputs(header, fp); - if (passphrase) { - fprintf(fp, "Proc-Type: 4,ENCRYPTED\nDEK-Info: DES-EDE3-CBC,"); - for (i = 0; i < 8; i++) - fprintf(fp, "%02X", iv[i]); - fprintf(fp, "\n\n"); - } base64_encode_fp(fp, outblob, outlen, 64); fputs(footer, fp); fclose(fp); From erik at hovland.org Fri Jul 7 05:49:40 2006 From: erik at hovland.org (Erik Hovland) Date: Thu, 6 Jul 2006 14:49:40 -0700 Subject: [patch] remove deadcode In-Reply-To: <20060705223314.GF18957@mage.jpl.nasa.gov> References: <20060705223314.GF18957@mage.jpl.nasa.gov> Message-ID: <20060706214940.GC26229@mage.jpl.nasa.gov> On Wed, Jul 05, 2006 at 03:33:14PM -0700, Erik Hovland wrote: > This patch removes an #if 0 set of code. And it removes a passphrase > check which cannot happen. I have finished an audit of dropbear and decided to reply to my own post because my current draft of patches expands on the same file (and a few others. The patches should be consistent with current mtn repo and should have annotations in each file. I am willing to rework any patch that doesn't meet the statisfaction of the devs. So please send feedback. BTW, almost all of these 'bugs' cause no harm that I can tell. So don't think there is any serious problems here. It is really just dotting i's and crossing t's. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request -------------- next part -------------- BUG: mp_div_2d returns status and it isn't checked. FIX: Check and return status. --- libtommath/bn_mp_div.c old +++ libtommath/bn_mp_div.c new @@ -269,7 +269,8 @@ int mp_div (mp_int * a, mp_int * b, mp_i } if (d != NULL) { - mp_div_2d (&x, norm, &x, NULL); + if ((res = mp_div_2d (&x, norm, &x, NULL)) != MP_OKAY) + return res; mp_exch (&x, d); } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "libtommath/bn_mp_div.c" # from [0f214a2ee7c1cfd6152ebd473d2f04db67f2f86c] # to [de1182b10274bd4e691094aef260abe21fb8f5cc] # -------------- next part -------------- BUG: The strings 'name' and 'instruction' are always allocated but are only freed if the length of the string is greater then zero. They should always be freed. FIX: take the m_free() out of the conditional --- cli-authinteract.c old +++ cli-authinteract.c new @@ -99,13 +99,13 @@ void recv_msg_userauth_info_request() { if (strlen(name) > 0) { cleantext(name); fprintf(stderr, "%s", name); - m_free(name); } + m_free(name); if (strlen(instruction) > 0) { cleantext(instruction); fprintf(stderr, "%s", instruction); - m_free(instruction); } + m_free(instruction); for (i = 0; i < num_prompts; i++) { unsigned int response_len = 0; # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "cli-authinteract.c" # from [c65d9c192f42ce4654ec4e8d6765b11e4f5ca9a9] # to [301ca11246ed5945026d0d1bc4c407ddc5a50519] # -------------- next part -------------- BUG: keybuf can memory leak. FIX: Add an m_free(keybuf) once we are done matching the keys. --- cli-authpubkey.c old +++ cli-authpubkey.c new @@ -112,6 +112,7 @@ void recv_msg_userauth_pk_ok() { /* Success */ break; } + m_free(keybuf); if (keyitem != NULL) { TRACE(("matching key")) # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "cli-authpubkey.c" # from [f4b6c66351e60851c73405d8ecf4676557f0da30] # to [05a5cc2282123b73b132a498c46279ac93d273a3] # -------------- next part -------------- BUG: The fingerprint can leak if response is not 'y'. FIX: Free the fingerprint buffer after we are done printing it. --- cli-kex.c old +++ cli-kex.c new @@ -122,6 +122,7 @@ static void ask_to_confirm(unsigned char fprintf(stderr, "\nHost '%s' is not in the trusted hosts file.\n(fingerprint %s)\nDo you want to continue connecting? (y/n)\n", cli_opts.remotehost, fp); + m_free(fp); tty = fopen(_PATH_TTY, "r"); if (tty) { @@ -132,7 +133,6 @@ static void ask_to_confirm(unsigned char } if (response == 'y') { - m_free(fp); return; } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "cli-kex.c" # from [3e15b2b2d3b42e45f38782414b709a48f11c56d9] # to [28231814a32f302b4dc82265fecf9d4850e5a001] # -------------- next part -------------- Remove a stale bit of code since it should be obvious waht is happening. --- cli-service.c old +++ cli-service.c new @@ -82,6 +82,4 @@ void recv_msg_service_accept() { } dropbear_exit("unrecognised service accept"); - /* m_free(servicename); not reached */ - } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "cli-service.c" # from [4b9ba5f1287845d47ba61d813ba53d143de4b804] # to [c9175c55722051be489796ffa96f171ac70f73c4] # -------------- next part -------------- BUG: The call find_cipher can return a negative value if things don't go right. We don't know that find_cipher is the cause of cbc_start() unless we check find_cipher before calling cbc_start(). BTW, cbc_start() does check that the cipher it is handed is OK. So there is no seriouse damage. FIX: Do the find_cipher() and check it. NOTE: I consider this fix to be purely pedantic. --- common-kex.c old +++ common-kex.c new @@ -262,6 +262,7 @@ void gen_new_keys() { hash_state hs; unsigned int C2S_keysize, S2C_keysize; char mactransletter, macrecvletter; /* Client or server specific */ + int recv_cipher = 0, trans_cipher = 0; TRACE(("enter gen_new_keys")) /* the dh_K and hash are the start of all hashes, we make use of that */ @@ -298,17 +299,21 @@ void gen_new_keys() { hashkeys(C2S_key, C2S_keysize, &hs, 'C'); hashkeys(S2C_key, S2C_keysize, &hs, 'D'); + if ((recv_cipher = find_cipher(ses.newkeys->recv_algo_crypt->cipherdesc->name)) < 0) + dropbear_exit("crypto error"); + if (cbc_start( - find_cipher(ses.newkeys->recv_algo_crypt->cipherdesc->name), - recv_IV, recv_key, + recv_cipher, recv_IV, recv_key, ses.newkeys->recv_algo_crypt->keysize, 0, &ses.newkeys->recv_symmetric_struct) != CRYPT_OK) { dropbear_exit("crypto error"); } + if ((trans_cipher = find_cipher(ses.newkeys->trans_algo_crypt->cipherdesc->name)) < 0) + dropbear_exit("crypto error"); + if (cbc_start( - find_cipher(ses.newkeys->trans_algo_crypt->cipherdesc->name), - trans_IV, trans_key, + trans_cipher, trans_IV, trans_key, ses.newkeys->trans_algo_crypt->keysize, 0, &ses.newkeys->trans_symmetric_struct) != CRYPT_OK) { dropbear_exit("crypto error"); @@ -517,7 +522,8 @@ void kexdh_comb_key(mp_int *dh_pub_us, m hash_state hs; /* read the prime and generator*/ - mp_init(&dh_p); + if (mp_init(&dh_p) != MP_OKAY) + dropbear_exit("Diffie-Hellman error"); bytes_to_mp(&dh_p, dh_p_val, DH_P_LEN); /* Check that dh_pub_them (dh_e or dh_f) is in the range [1, p-1] */ # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "common-kex.c" # from [b06f424fe466a6d3ecfb7072d59457ebb39c8780] # to [a5be345f9dd6aa724d95134f13a4fe36bf83320e] # -------------- next part -------------- BUG: The call to sign_key_free(key) could be called before key is allocated because of the goto usage. FIX: Check key before making the call. --- dropbearkey.c old +++ dropbearkey.c new @@ -283,8 +283,10 @@ out: buf_burn(buf); buf_free(buf); buf = NULL; - sign_key_free(key); - key = NULL; + if (key) { + sign_key_free(key); + key = NULL; + } exit(err); } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "dropbearkey.c" # from [c2a49c53fa12e4bf57922462e55b243119bb4043] # to [eb8195c08cabcd2516d8fb5a461b4fa29e933cf0] # -------------- next part -------------- BUG: We could leak the file descriptor in certain cases. FIX: Add an fclose to the calls if we had to do an explicit fopen. BUG: The switch to using a goto instead of the code in the conditional block makes the following 'if (passphrase)' call redundant. NOTE: The code in the #if 0 comments is removed as well. --- keyimport.c old +++ keyimport.c new @@ -362,6 +362,7 @@ static struct openssh_key *load_openssh_ { struct openssh_key *ret; FILE *fp; + int close_fp = 0; char buffer[256]; char *errmsg = NULL, *p = NULL; int headers_done; @@ -377,9 +378,12 @@ static struct openssh_key *load_openssh_ fp = stdin; } else { fp = fopen(filename, "r"); + close_fp = 1; } if (!fp) { errmsg = "Unable to open key file"; + if (close_fp) + close_fp = 0; goto error; } if (!fgets(buffer, sizeof(buffer), fp) || @@ -482,6 +486,8 @@ static struct openssh_key *load_openssh_ memset(&ret, 0, sizeof(ret)); m_free(ret); } + if (close_fp) + fclose(fp); if (errmsg) { fprintf(stderr, "Error: %s\n", errmsg); } @@ -926,40 +932,6 @@ static int openssh_write(const char *fil if (passphrase) { fprintf(stderr, "Encrypted keys aren't supported currently\n"); goto error; -#if 0 - /* - * Invent an iv. Then derive encryption key from passphrase - * and iv/salt: - * - * - let block A equal MD5(passphrase || iv) - * - let block B equal MD5(A || passphrase || iv) - * - block C would be MD5(B || passphrase || iv) and so on - * - encryption key is the first N bytes of A || B - */ - struct MD5Context md5c; - unsigned char keybuf[32]; - - for (i = 0; i < 8; i++) iv[i] = random_byte(); - - MD5Init(&md5c); - MD5Update(&md5c, (unsigned char *)passphrase, strlen(passphrase)); - MD5Update(&md5c, iv, 8); - MD5Final(keybuf, &md5c); - - MD5Init(&md5c); - MD5Update(&md5c, keybuf, 16); - MD5Update(&md5c, (unsigned char *)passphrase, strlen(passphrase)); - MD5Update(&md5c, iv, 8); - MD5Final(keybuf+16, &md5c); - - /* - * Now encrypt the key blob. - */ - des3_encrypt_pubkey_ossh(keybuf, iv, outblob, outlen); - - memset(&md5c, 0, sizeof(md5c)); - memset(keybuf, 0, sizeof(keybuf)); -#endif } /* @@ -976,12 +948,6 @@ static int openssh_write(const char *fil goto error; } fputs(header, fp); - if (passphrase) { - fprintf(fp, "Proc-Type: 4,ENCRYPTED\nDEK-Info: DES-EDE3-CBC,"); - for (i = 0; i < 8; i++) - fprintf(fp, "%02X", iv[i]); - fprintf(fp, "\n\n"); - } base64_encode_fp(fp, outblob, outlen, 64); fputs(footer, fp); fclose(fp); # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "keyimport.c" # from [4d6aa56819151b18d6828b1a9b1db0b9864e40b3] # to [61087db466ee8df9c0fc12f65affa660f62ab9ea] # -------------- next part -------------- BUG: The libtommath call mp_invmod does return a value but it is not checked. FIX: Add a check. --- rsa.c old +++ rsa.c new @@ -286,7 +286,8 @@ void buf_put_rsa_sign(buffer* buf, rsa_k /* em' = em * r^e mod n */ mp_exptmod(&rsa_tmp2, key->e, key->n, &rsa_s); /* rsa_s used as a temp var*/ - mp_invmod(&rsa_tmp2, key->n, &rsa_tmp3); + if (mp_invmod(&rsa_tmp2, key->n, &rsa_tmp3) != MP_OKAY) + dropbear_exit("rsa error"); mp_mulmod(&rsa_tmp1, &rsa_s, key->n, &rsa_tmp2); /* rsa_tmp2 is em' */ # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "rsa.c" # from [792f3ff06fe126d3b69a067e56be005c57c8c968] # to [9849a7e08b3d656e9deb9c9330499359a1e3b961] # -------------- next part -------------- BUG: Potentially dangeruous use of stat/chown/chmod. Since we use the string tty_name for all calls on the tty device it is possible for someone to be underhanded and use these calls and that string to elevate priviledges. FIX: Switch to using fstat/fchown/fchmod and obtain a file descriptor instead of using a string. NOTE: I doubt this can be exploited. But why leave it hanging around. --- sshpty.c old +++ sshpty.c new @@ -356,6 +356,7 @@ void pty_setowner(struct passwd *pw, const char *tty_name) { struct group *grp; + FILE* ttyfd; gid_t gid; mode_t mode; struct stat st; @@ -375,21 +376,25 @@ pty_setowner(struct passwd *pw, const ch * Warn but continue if filesystem is read-only and the uids match/ * tty is owned by root. */ - if (stat(tty_name, &st)) { - dropbear_exit("pty_setowner: stat(%.101s) failed: %.100s", + if (!(ttyfd = fopen(tty_name, "w+"))) { + dropbear_exit("pty_setowner: fopen(%.101s) failed: %.100s", + tty_name, strerror(errno)); + } + if (fstat(ttyfd, &st)) { + dropbear_exit("pty_setowner: fstat(%.101s) failed: %.100s", tty_name, strerror(errno)); } if (st.st_uid != pw->pw_uid || st.st_gid != gid) { - if (chown(tty_name, pw->pw_uid, gid) < 0) { + if (fchown(ttyfd, pw->pw_uid, gid) < 0) { if (errno == EROFS && (st.st_uid == pw->pw_uid || st.st_uid == 0)) { dropbear_log(LOG_ERR, - "chown(%.100s, %u, %u) failed: %.100s", + "fchown(%.100s, %u, %u) failed: %.100s", tty_name, (unsigned int)pw->pw_uid, (unsigned int)gid, strerror(errno)); } else { - dropbear_exit("chown(%.100s, %u, %u) failed: %.100s", + dropbear_exit("fchown(%.100s, %u, %u) failed: %.100s", tty_name, (unsigned int)pw->pw_uid, (unsigned int)gid, strerror(errno)); } @@ -397,16 +402,18 @@ pty_setowner(struct passwd *pw, const ch } if ((st.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)) != mode) { - if (chmod(tty_name, mode) < 0) { + if (fchmod(ttyfd, mode) < 0) { if (errno == EROFS && (st.st_mode & (S_IRGRP | S_IROTH)) == 0) { dropbear_log(LOG_ERR, - "chmod(%.100s, 0%o) failed: %.100s", + "fchmod(%.100s, 0%o) failed: %.100s", tty_name, mode, strerror(errno)); } else { - dropbear_exit("chmod(%.100s, 0%o) failed: %.100s", + dropbear_exit("fchmod(%.100s, 0%o) failed: %.100s", tty_name, mode, strerror(errno)); } } } + if (ttyfd) + fclose(ttyfd); } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "sshpty.c" # from [5f45b06f6c68c3a4b163a7caf5efd681cd2dd7b8] # to [ead81d13baa32bcdb4394eb04e920b289e52df06] # -------------- next part -------------- BUG: Since exit is set to NULL at the end of the loop, it is possible to dereference exit as NULL (and segfault). FIX: Co-opt the check for the race condition to make sure that exit points at something valid. --- svr-chansession.c old +++ svr-chansession.c new @@ -99,7 +99,7 @@ static void sesssigchild_handler(int UNU /* If the pid wasn't matched, then we might have hit the race mentioned * above. So we just store the info for the parent to deal with */ - if (i == svr_ses.childpidsize) { + if (i == svr_ses.childpidsize || !exit) { exit = &svr_ses.lastexit; } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "svr-chansession.c" # from [030d10c1bd3ddf7d5e1a85165ee24685214a6b48] # to [609b0035bc1da3b426ac09adf1780a03aaf6c70e] # -------------- next part -------------- BUG: buf_getmpint() is not checked to see if it worked. FIX: Add a check and exit if it doesn't. --- svr-kex.c old +++ svr-kex.c new @@ -52,7 +52,8 @@ void recv_msg_kexdh_init() { } m_mp_init(&dh_e); - buf_getmpint(ses.payload, &dh_e); + if (buf_getmpint(ses.payload, &dh_e) != DROPBEAR_SUCCESS) + dropbear_exit("Unable to retrieve mp_int from buffer"); send_msg_kexdh_reply(&dh_e); # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "svr-kex.c" # from [307e41123e5a9962093a7285f73a2400916bf526] # to [0e5589d22c3cc3c0fc1e84a13d4734c463ac3e9f] # -------------- next part -------------- BUG: If you use the pointer that is obtained from tcpinfo and tcpinfo is NULL this call will segfault. FIX: Use the pointer var bindaddr instead since it is the same thing. --- svr-tcpfwd.c old +++ svr-tcpfwd.c new @@ -216,7 +216,7 @@ out: if (ret == DROPBEAR_FAILURE) { /* we only free it if a listener wasn't created, since the listener * has to remember it if it's to be cancelled */ - m_free(tcpinfo->listenaddr); + m_free(bindaddr); m_free(tcpinfo); } TRACE(("leave remotetcpreq")) # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "svr-tcpfwd.c" # from [aa3d9bd98b61f4a84f5b28b1debc66a2b398045b] # to [dba94b5f63e6e5cfcc4eb61809f890715c8eacf5] # -------------- next part -------------- BUG: Since listen_tcpfwd() does not free the buffer that tcpinfo points to when it notices a check in a previous block of code, it is inconsistent to free tcpinfo in this check. Especially since the call is responsible for giving a valid pointer to listen_tcpfwd(). FIX: Remove the m_free(tcpinfo); call so that listen_tcpfwd() always behaves the same when bailing out. --- tcp-accept.c old +++ tcp-accept.c new @@ -131,7 +131,6 @@ int listen_tcpfwd(struct TCPListener* tc tcp_acceptor, cleanup_tcp); if (listener == NULL) { - m_free(tcpinfo); TRACE(("leave listen_tcpfwd: listener failed")) return DROPBEAR_FAILURE; } # # old_revision [4c32ad8064e93b83c6d635d193b34d5f9112d1ae] # # patch "tcp-accept.c" # from [30c320bfdcfb7fd4dfbb35d8af5afdb1778f1d7d] # to [69b03a9fd536daae6f43bc740522947591247de0] # From matt at ucc.asn.au Fri Jul 7 18:02:53 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 7 Jul 2006 18:02:53 +0800 Subject: [patch] remove deadcode In-Reply-To: <20060706214940.GC26229@mage.jpl.nasa.gov> References: <20060705223314.GF18957@mage.jpl.nasa.gov> <20060706214940.GC26229@mage.jpl.nasa.gov> Message-ID: <20060707100253.GZ12898@ucc.gu.uwa.edu.au> On Thu, Jul 06, 2006 at 02:49:40PM -0700, Erik Hovland wrote: > I have finished an audit of dropbear and decided to reply to my own post > because my current draft of patches expands on the same file (and a few > others. > > The patches should be consistent with current mtn repo and should have > annotations in each file. I am willing to rework any patch that doesn't > meet the statisfaction of the devs. So please send feedback. Thanks for the eyeballing and patches. I've applied most of them with only minor changes. With the svr-chansession.c exit patch I think the current code is correct, as the exit value will only be unset when i == svr_ses.childpidsize. I've modified the code to be a bit clearer anyway. For the ssh-pty.c patch, I don't think this improves the security/correctness much. tty_name is always a /dev/ttyXXX device, and if an attacker can manipulate paths in /dev/, then there are larger problems. Does that analysis sound reasonable? Cheers, Matt (PS, if you're using the monotone head, beware that there's a known issue that can cause it to wait for input when closing on Linux.) > BUG: Potentially dangeruous use of stat/chown/chmod. Since we use the > string tty_name for all calls on the tty device it is possible for > someone to be underhanded and use these calls and that string > to elevate priviledges. > > FIX: Switch to using fstat/fchown/fchmod and obtain a file > descriptor instead of using a string. > > NOTE: I doubt this can be exploited. But why leave it hanging around. > --- sshpty.c old +++ sshpty.c new @@ -356,6 +356,7 @@ void pty_setowner(struct passwd *pw, const char *tty_name) { struct group *grp; + FILE* ttyfd; gid_t gid; mode_t mode; struct stat st; @@ -375,21 +376,25 @@ pty_setowner(struct passwd *pw, const ch * Warn but continue if filesystem is read-only and the uids match/ * tty is owned by root. */ - if (stat(tty_name, &st)) { - dropbear_exit("pty_setowner: stat(%.101s) failed: %.100s", + if (!(ttyfd = fopen(tty_name, "w+"))) { + dropbear_exit("pty_setowner: fopen(%.101s) failed: %.100s", + tty_name, strerror(errno)); + } + if (fstat(ttyfd, &st)) { + dropbear_exit("pty_setowner: fstat(%.101s) failed: %.100s", tty_name, strerror(errno)); } if (st.st_uid != pw->pw_uid || st.st_gid != gid) { - if (chown(tty_name, pw->pw_uid, gid) < 0) { + if (fchown(ttyfd, pw->pw_uid, gid) < 0) { if (errno == EROFS && (st.st_uid == pw->pw_uid || st.st_uid == 0)) { dropbear_log(LOG_ERR, - "chown(%.100s, %u, %u) failed: %.100s", + "fchown(%.100s, %u, %u) failed: %.100s", tty_name, (unsigned int)pw->pw_uid, (unsigned int)gid, strerror(errno)); } else { - dropbear_exit("chown(%.100s, %u, %u) failed: %.100s", + dropbear_exit("fchown(%.100s, %u, %u) failed: %.100s", tty_name, (unsigned int)pw->pw_uid, (unsigned int)gid, strerror(errno)); } @@ -397,16 +402,18 @@ pty_setowner(struct passwd *pw, const ch } if ((st.st_mode & (S_IRWXU|S_IRWXG|S_IRWXO)) != mode) { - if (chmod(tty_name, mode) < 0) { + if (fchmod(ttyfd, mode) < 0) { if (errno == EROFS && (st.st_mode & (S_IRGRP | S_IROTH)) == 0) { dropbear_log(LOG_ERR, - "chmod(%.100s, 0%o) failed: %.100s", + "fchmod(%.100s, 0%o) failed: %.100s", tty_name, mode, strerror(errno)); } else { - dropbear_exit("chmod(%.100s, 0%o) failed: %.100s", + dropbear_exit("fchmod(%.100s, 0%o) failed: %.100s", tty_name, mode, strerror(errno)); } } } + if (ttyfd) + fclose(ttyfd); } From erik at hovland.org Sat Jul 8 02:30:11 2006 From: erik at hovland.org (Erik Hovland) Date: Fri, 7 Jul 2006 11:30:11 -0700 Subject: [patch] remove deadcode In-Reply-To: <20060707100253.GZ12898@ucc.gu.uwa.edu.au> References: <20060705223314.GF18957@mage.jpl.nasa.gov> <20060706214940.GC26229@mage.jpl.nasa.gov> <20060707100253.GZ12898@ucc.gu.uwa.edu.au> Message-ID: <20060707183011.GA20702@mage.jpl.nasa.gov> On Fri, Jul 07, 2006 at 06:02:53PM +0800, Matt Johnston wrote: > With the svr-chansession.c exit patch I think the current > code is correct, as the exit value will only be unset when > i == svr_ses.childpidsize. I've modified the code to be a > bit clearer anyway. > > For the ssh-pty.c patch, I don't think this improves the > security/correctness much. tty_name is always a /dev/ttyXXX > device, and if an attacker can manipulate paths in /dev/, then > there are larger problems. Does that analysis sound > reasonable? Both sound fine to me. As far as an attacker manipulating something. All they really have to manipulate is the string of the tty_name between the stat and the chown. Granted, this isn't easy either. But is the real reason for the patch. As I said, it isn't serious - just trying to be complete. > (PS, if you're using the monotone head, beware that there's > a known issue that can cause it to wait for input when > closing on Linux.) I am only using it for testing and auditing. Thanks for the quick attention. E -- Erik Hovland mail: erik AT hovland DOT org web: http://hovland.org/ PGP/GPG public key available on request From art at sigrand.ru Fri Jul 14 14:13:35 2006 From: art at sigrand.ru (art) Date: Fri, 14 Jul 2006 13:13:35 +0700 Subject: dropbear login problem. Message-ID: <1551.060714@sigrand.ru> Hello dropbear, Hi all I work with mips embedded linux system Kernel 2.6.16 uClibc 0.9.28 I have some problem with dropbear - i cannot login from my host machine. host client writes: # ssh root at 192.168.3.2 root at 192.168.3.2's password: Connection to 192.168.3.2 closed. in the logs at my embedded system i get: Jan 1 00:26:24 localhost authpriv.info dropbear[1135]: Child connection from 192.168.3.1:46781 Jan 1 00:26:27 localhost authpriv.notice dropbear[1135]: password auth succeeded for 'root' from 192.168.3.1:46781 Jan 1 00:26:27 localhost authpriv.info dropbear[1135]: exit after auth (root): Exited normally And nothing more :( -- Best regards, art mailto:art at sigrand.ru From wimpunk at gmail.com Fri Jul 14 14:44:58 2006 From: wimpunk at gmail.com (Wim Vinckier) Date: Fri, 14 Jul 2006 08:44:58 +0200 Subject: dropbear login problem. In-Reply-To: <1551.060714@sigrand.ru> References: <1551.060714@sigrand.ru> Message-ID: <5c43128e0607132344m6dc1d811m3d2d39bc78207a8f@mail.gmail.com> On 7/14/06, art wrote: > Hello dropbear, > Hi all > I work with mips embedded linux system > Kernel 2.6.16 > uClibc 0.9.28 > I have some problem with dropbear - i cannot login from my host > machine. > > host client writes: > # ssh root at 192.168.3.2 > root at 192.168.3.2's password: > Connection to 192.168.3.2 closed. > > in the logs at my embedded system i get: > Jan 1 00:26:24 localhost authpriv.info dropbear[1135]: Child connection from 192.168.3.1:46781 > Jan 1 00:26:27 localhost authpriv.notice dropbear[1135]: password auth succeeded for 'root' from 192.168.3.1:46781 > Jan 1 00:26:27 localhost authpriv.info dropbear[1135]: exit after auth (root): Exited normally > > And nothing more :( > > -- > Best regards, > art mailto:art at sigrand.ru > > > > > I got the same problem because of a wrong SHELL setting. My 50cent, wim. From wimpunk at gmail.com Fri Jul 14 15:51:13 2006 From: wimpunk at gmail.com (Wim Vinckier) Date: Fri, 14 Jul 2006 09:51:13 +0200 Subject: dropbear login problem. In-Reply-To: <4613.060714@sigrand.ru> References: <5c43128e0607132344m6dc1d811m3d2d39bc78207a8f@mail.gmail.com> <4613.060714@sigrand.ru> Message-ID: <5c43128e0607140051w6cef36e6g813105d4edf0ea25@mail.gmail.com> Just letting the list knowing the answer... wim. On 7/14/06, art wrote: > Hello Wim, > > Friday, July 14, 2006, 1:44:58 PM, you wrote: > > WV> On 7/14/06, art wrote: > >> Hello dropbear, > >> Hi all > >> I work with mips embedded linux system > >> Kernel 2.6.16 > >> uClibc 0.9.28 > >> I have some problem with dropbear - i cannot login from my host > >> machine. > >> > >> host client writes: > >> # ssh root at 192.168.3.2 > >> root at 192.168.3.2's password: > >> Connection to 192.168.3.2 closed. > >> > >> in the logs at my embedded system i get: > >> Jan 1 00:26:24 localhost authpriv.info dropbear[1135]: Child connection from 192.168.3.1:46781 > >> Jan 1 00:26:27 localhost authpriv.notice dropbear[1135]: password auth succeeded for 'root' from 192.168.3.1:46781 > >> Jan 1 00:26:27 localhost authpriv.info dropbear[1135]: exit after auth (root): Exited normally > >> > >> And nothing more :( > >> > >> -- > >> Best regards, > >> art mailto:art at sigrand.ru > >> > >> > >> > >> > >> > > WV> I got the same problem because of a wrong SHELL setting. > > WV> My 50cent, > > WV> wim. > > Thanks! > Solved :) home dir for root - /root was missing. I create it - all > works > > > -- > Best regards, > art mailto:art at sigrand.ru > > > From jsujjavanich at syntech-fuelmaster.com Fri Jul 14 23:54:40 2006 From: jsujjavanich at syntech-fuelmaster.com (Jate Sujjavanich) Date: Fri, 14 Jul 2006 11:54:40 -0400 Subject: dropbear received data with bad writefd Message-ID: I am attempting to get Dropbear 0.47 working for m68knommu/Coldfire working for uClinux. I configured with the --disable-openpty. I undefined HAVE_GETPTY. I set up dropbear as a inetd service, and I can login. When the shell is supposed to come up, I get the following messages from the dropbear server log: <6>Jul 14 11:44:20 dropbear[171]: Child connection from 192.168.120.6:52911 <5>Jul 14 11:44:54 dropbear[171]: password auth succeeded for 'root' from 192.16 8.120.6:52911 <6>Jul 14 11:44:59 dropbear[171]: exit after auth (root): received data with bad writefd <6>Jul 14 11:45:02 dropbear[172]: Child connection from 192.168.120.6:52912 I get the following messages from the ssh client: root at 192.168.121.37's password: debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug2: channel 0: request shell confirm 0 debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 8000 rmax 8000 debug1: channel 0: free: client-session, nchannels 1 Connection to 192.168.121.37 closed by remote host. Connection to 192.168.121.37 closed. debug1: Transferred: stdin 0, stdout 0, stderr 91 bytes in 17.3 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 5.2 debug1: Exit status -1 Do you have any suggestions? - Jate S. From ndprasad at gmail.com Sat Jul 15 09:13:44 2006 From: ndprasad at gmail.com (Prasad) Date: Fri, 14 Jul 2006 18:13:44 -0700 Subject: Dropbear calling my own command-line parser than /bin/sh. Message-ID: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> Hi all, How do i make dropbear call my own utility/command-line parser which has its own way of checking the username and password and does some other work. How do i integrate that with the dropbear-ssh (in this way i can get my code to get run using SSH and not the default /bin/sh). Appreciate your response. Thanx - Prasad From matt at ucc.asn.au Sat Jul 15 10:18:27 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 15 Jul 2006 10:18:27 +0800 Subject: dropbear received data with bad writefd In-Reply-To: References: Message-ID: <20060715021827.GA12898@ucc.gu.uwa.edu.au> On Fri, Jul 14, 2006 at 11:54:40AM -0400, Jate Sujjavanich wrote: > I set up dropbear as a inetd service, and I can login. When the shell is > supposed to come up, I get the following messages from the dropbear > server log: > > <6>Jul 14 11:44:59 dropbear[171]: exit after auth (root): received data > with bad > writefd Could you compile Dropbear with DEBUG_TRACE enabled in debug.h, and run it as a standalone server and with the -v flag? That should give a bit more detail. The output of ssh -vvv for the client might also be useful. The error message occurs when the server receives data on a channel that it thinks is already closed. Most likely it's a logic error somewhere in the channel handling code - I need to fix some things there. Cheers, Matt From matt at ucc.asn.au Sat Jul 15 10:25:53 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 15 Jul 2006 10:25:53 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh. In-Reply-To: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> References: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> Message-ID: <20060715022553.GB12898@ucc.gu.uwa.edu.au> On Fri, Jul 14, 2006 at 06:13:44PM -0700, Prasad wrote: > Hi all, > How do i make dropbear call my own utility/command-line parser which > has its own way of checking the username and password and does some > other work. Have a look at svr_auth_password() in svr-authpasswd.c for how the existing password checking works. You could make it run a hardcoded system() call (beware of allowing arbitrary input), and then check the return value of the program? Note that if the user doesn't exist in /etc/passwd, then you'll have to manually fill out the entries in the ses.authstate.pw structure. Look out for the code in svr-auth.c that checks that a shell is valid - you may want to disable that. > How do i integrate that with the dropbear-ssh (in this way > i can get my code to get run using SSH and not the default > /bin/sh). If you're using /etc/passwd still, just change the shell there (and /etc/shells). Otherwise, change the shell that is filled out in the ses.authstate.pw structure during auth. The shell to execute is taken from ses.authstate.pw->pw_shell in svr-chansession.c. The shell is run as "sh -c 'command line arguments'", so you might want to change that (or just have your own shell ignore arguments). Matt From ndprasad at gmail.com Tue Jul 18 02:22:29 2006 From: ndprasad at gmail.com (Prasad) Date: Mon, 17 Jul 2006 11:22:29 -0700 Subject: dropbear received data with bad writefd In-Reply-To: <20060715021827.GA12898@ucc.gu.uwa.edu.au> References: <20060715021827.GA12898@ucc.gu.uwa.edu.au> Message-ID: <3351bfbe0607171122lb4d33a1hf6abf42130329730@mail.gmail.com> Hi matt, I also got the same kinda error after i get the login and enter passwd. My platform is uClinux+microblaze. I moved from the default dropbear version in uClinux (0.43 which worked perfect) to dropbearversion-0.48. I have attached the log (running with debug enabled) with this mail. Please let me know what i have missed. I will continue debugging meanwhile. Thanx - Prasad On 7/14/06, Matt Johnston wrote: > On Fri, Jul 14, 2006 at 11:54:40AM -0400, Jate Sujjavanich wrote: > > I set up dropbear as a inetd service, and I can login. When the shell is > > supposed to come up, I get the following messages from the dropbear > > server log: > > > > <6>Jul 14 11:44:59 dropbear[171]: exit after auth (root): received data > > with bad > > writefd > > Could you compile Dropbear with DEBUG_TRACE enabled in > debug.h, and run it as a standalone server and with the -v > flag? That should give a bit more detail. > > The output of ssh -vvv for the client might also be useful. > The error message occurs when the server receives data on a > channel that it thinks is already closed. Most likely it's a > logic error somewhere in the channel handling code - I need > to fix some things there. > > > Cheers, > Matt > > -------------- next part -------------- A non-text attachment was scrubbed... Name: debugtrace Type: application/octet-stream Size: 9012 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060717/320b40a0/debugtrace.obj From jsujjavanich at syntech-fuelmaster.com Tue Jul 18 03:00:30 2006 From: jsujjavanich at syntech-fuelmaster.com (Jate Sujjavanich) Date: Mon, 17 Jul 2006 15:00:30 -0400 Subject: dropbear received data with bad writefd Message-ID: I have solved the problem by changing all the fork()'s in the code to vfork()'s. - Jate S. -----Original Message----- From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] On Behalf Of Prasad Sent: Monday, July 17, 2006 2:22 PM To: dropbear at ucc.asn.au Subject: Re: dropbear received data with bad writefd Hi matt, I also got the same kinda error after i get the login and enter passwd. My platform is uClinux+microblaze. I moved from the default dropbear version in uClinux (0.43 which worked perfect) to dropbearversion-0.48. I have attached the log (running with debug enabled) with this mail. Please let me know what i have missed. I will continue debugging meanwhile. Thanx - Prasad On 7/14/06, Matt Johnston wrote: > On Fri, Jul 14, 2006 at 11:54:40AM -0400, Jate Sujjavanich wrote: > > I set up dropbear as a inetd service, and I can login. When the > > shell is supposed to come up, I get the following messages from the > > dropbear server log: > > > > <6>Jul 14 11:44:59 dropbear[171]: exit after auth (root): received > > data with bad writefd > > Could you compile Dropbear with DEBUG_TRACE enabled in debug.h, and > run it as a standalone server and with the -v flag? That should give a > bit more detail. > > The output of ssh -vvv for the client might also be useful. > The error message occurs when the server receives data on a channel > that it thinks is already closed. Most likely it's a logic error > somewhere in the channel handling code - I need to fix some things > there. > > > Cheers, > Matt > > From ndprasad at gmail.com Tue Jul 18 03:21:07 2006 From: ndprasad at gmail.com (Prasad) Date: Mon, 17 Jul 2006 12:21:07 -0700 Subject: dropbear received data with bad writefd In-Reply-To: References: Message-ID: <3351bfbe0607171221w41b25f77yed57115b8f9624b8@mail.gmail.com> Just no checked. Actually for me, the problem seems to go away when i changed Makefile to include all the compilable option passed by the main makefile from the uClinux-dist. # CFLAGS=-I. -I$(srcdir)/libtomcrypt/src/headers/ -Os -W -Wall CFLAGS+=-I. -I$(srcdir)/libtomcrypt/src/headers/ -Os Thanx - DeviPrasad On 7/17/06, Jate Sujjavanich wrote: > I have solved the problem by changing all the fork()'s in the code to > vfork()'s. > > - Jate S. > > -----Original Message----- > From: dropbear-bounces at ucc.asn.au [mailto:dropbear-bounces at ucc.asn.au] > On Behalf Of Prasad > Sent: Monday, July 17, 2006 2:22 PM > To: dropbear at ucc.asn.au > Subject: Re: dropbear received data with bad writefd > > Hi matt, > I also got the same kinda error after i get the login and enter passwd. > My platform is uClinux+microblaze. I moved from the default dropbear > version in uClinux (0.43 which worked perfect) to dropbearversion-0.48. > > I have attached the log (running with debug enabled) with this mail. > Please let me know what i have missed. I will continue debugging > meanwhile. > > Thanx > - Prasad > > On 7/14/06, Matt Johnston wrote: > > On Fri, Jul 14, 2006 at 11:54:40AM -0400, Jate Sujjavanich wrote: > > > I set up dropbear as a inetd service, and I can login. When the > > > shell is supposed to come up, I get the following messages from the > > > dropbear server log: > > > > > > <6>Jul 14 11:44:59 dropbear[171]: exit after auth (root): received > > > data with bad writefd > > > > Could you compile Dropbear with DEBUG_TRACE enabled in debug.h, and > > run it as a standalone server and with the -v flag? That should give a > > > bit more detail. > > > > The output of ssh -vvv for the client might also be useful. > > The error message occurs when the server receives data on a channel > > that it thinks is already closed. Most likely it's a logic error > > somewhere in the channel handling code - I need to fix some things > > there. > > > > > > Cheers, > > Matt > > > > > > > From ndprasad at gmail.com Tue Jul 18 12:53:52 2006 From: ndprasad at gmail.com (Prasad) Date: Mon, 17 Jul 2006 21:53:52 -0700 Subject: Dropbear calling my own command-line parser than /bin/sh. In-Reply-To: <20060715022553.GB12898@ucc.gu.uwa.edu.au> References: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> <20060715022553.GB12898@ucc.gu.uwa.edu.au> Message-ID: <3351bfbe0607172153l2017b295j69d8b3f3156db35a@mail.gmail.com> Hi matt, Thanx for the response. I changed as u suggested and put dummy password authentication and it worked. Now i have a question. Actually the commandline interpreter i call has its own username and password authentication (which doesn't use /etc/passwd). So now i want to totally skip the regular username and password in the SSH and directly call my commandline interpreter (which has a password autentication by itself). How do i achieve that? Is there any security flaws in this kinda design. Thanx - Prasad On 7/14/06, Matt Johnston wrote: > On Fri, Jul 14, 2006 at 06:13:44PM -0700, Prasad wrote: > > Hi all, > > How do i make dropbear call my own utility/command-line parser which > > has its own way of checking the username and password and does some > > other work. > > Have a look at svr_auth_password() in svr-authpasswd.c for > how the existing password checking works. You could make it > run a hardcoded system() call (beware of allowing arbitrary > input), and then check the return value of the program? Note > that if the user doesn't exist in /etc/passwd, then you'll > have to manually fill out the entries in the > ses.authstate.pw structure. Look out for the code in > svr-auth.c that checks that a shell is valid - you may want > to disable that. > > > How do i integrate that with the dropbear-ssh (in this way > > i can get my code to get run using SSH and not the default > > /bin/sh). > > If you're using /etc/passwd still, just change the shell > there (and /etc/shells). Otherwise, change the shell that is > filled out in the ses.authstate.pw structure during auth. > The shell to execute is taken from > ses.authstate.pw->pw_shell in svr-chansession.c. The shell > is run as "sh -c 'command line arguments'", so you might > want to change that (or just have your own shell ignore > arguments). > > Matt > > From matt at ucc.asn.au Tue Jul 18 14:00:49 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 18 Jul 2006 14:00:49 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh. In-Reply-To: <3351bfbe0607172153l2017b295j69d8b3f3156db35a@mail.gmail.com> References: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> <20060715022553.GB12898@ucc.gu.uwa.edu.au> <3351bfbe0607172153l2017b295j69d8b3f3156db35a@mail.gmail.com> Message-ID: <20060718060049.GM28731@ucc.gu.uwa.edu.au> On Mon, Jul 17, 2006 at 09:53:52PM -0700, Prasad wrote: > Hi matt, > Thanx for the response. I changed as u suggested and put dummy > password authentication and it worked. > > Now i have a question. Actually the commandline interpreter i call has > its own username and password authentication (which doesn't use > /etc/passwd). So now i want to totally skip the regular username and > password in the SSH and directly call my commandline interpreter > (which has a password autentication by itself). How do i achieve that? > Is there any security flaws in this kinda design. Something like the patch below should work for setting a hardcoded user and allowing authentication immediately. I think it should be secure, as long as you make sure that you're ignoring requests for different commands from the user (which will get passed as arguments to your interpreter), and your interpreter itself is secure. Matt # # old_revision [b59d9b3648d8fc72e8702a1013a1c6926d46ab2e] # # patch "svr-auth.c" # from [dbd28ab1fff172ca3f2e4cb756ec53b74b48b6b3] # to [2bf6cc2b096ba97f0614119414b9cd25a73fddfb] # ============================================================ --- svr-auth.c dbd28ab1fff172ca3f2e4cb756ec53b74b48b6b3 +++ svr-auth.c 2bf6cc2b096ba97f0614119414b9cd25a73fddfb @@ -108,7 +108,10 @@ } - username = buf_getstring(ses.payload, &userlen); + /* fake the username */ + username = m_strdup("matt"); + buf_eatstring(ses.payload); + servicename = buf_getstring(ses.payload, &servicelen); methodname = buf_getstring(ses.payload, &methodlen); @@ -134,52 +137,16 @@ } /* check username is good before continuing */ - if (checkusername(username, userlen) == DROPBEAR_FAILURE) { + if (checkusername(username, strlen(username)) == DROPBEAR_FAILURE) { /* username is invalid/no shell/etc - send failure */ TRACE(("sending checkusername failure")) send_msg_userauth_failure(0, 1); goto out; } -#ifdef ENABLE_SVR_PASSWORD_AUTH - if (!svr_opts.noauthpass && - !(svr_opts.norootpass && ses.authstate.pw->pw_uid == 0) ) { - /* user wants to try password auth */ - if (methodlen == AUTH_METHOD_PASSWORD_LEN && - strncmp(methodname, AUTH_METHOD_PASSWORD, - AUTH_METHOD_PASSWORD_LEN) == 0) { - svr_auth_password(); - goto out; - } - } -#endif - -#ifdef ENABLE_SVR_PAM_AUTH - if (!svr_opts.noauthpass && - !(svr_opts.norootpass && ses.authstate.pw->pw_uid == 0) ) { - /* user wants to try password auth */ - if (methodlen == AUTH_METHOD_PASSWORD_LEN && - strncmp(methodname, AUTH_METHOD_PASSWORD, - AUTH_METHOD_PASSWORD_LEN) == 0) { - svr_auth_pam(); - goto out; - } - } -#endif - -#ifdef ENABLE_SVR_PUBKEY_AUTH - /* user wants to try pubkey auth */ - if (methodlen == AUTH_METHOD_PUBKEY_LEN && - strncmp(methodname, AUTH_METHOD_PUBKEY, - AUTH_METHOD_PUBKEY_LEN) == 0) { - svr_auth_pubkey(); - goto out; - } -#endif - - /* nothing matched, we just fail */ - send_msg_userauth_failure(0, 1); - + /* allow login */ + dropbear_log(LOG_NOTICE, "fake auth succeeded from %s", svr_ses.addrstring); + send_msg_userauth_success(); out: m_free(username); From ndprasad at gmail.com Wed Jul 19 09:53:18 2006 From: ndprasad at gmail.com (Prasad) Date: Tue, 18 Jul 2006 18:53:18 -0700 Subject: Dropbear calling my own command-line parser than /bin/sh. In-Reply-To: <20060718060049.GM28731@ucc.gu.uwa.edu.au> References: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> <20060715022553.GB12898@ucc.gu.uwa.edu.au> <3351bfbe0607172153l2017b295j69d8b3f3156db35a@mail.gmail.com> <20060718060049.GM28731@ucc.gu.uwa.edu.au> Message-ID: <3351bfbe0607181853l5b18658mcf5fe16a1856dc37@mail.gmail.com> Matt, Changed as per your suggestion and it worked perfectly well. Thanx for that. The only problem now i have is that the entire process is really slow until i get the login. I takes about 90 secs for me to get the shell. (With or with-out the changes for my own interpreter). After i get login everything is pretty fast. The size of the SSH key is 1024 bit. (512 bytes reduces the time by about 60 secs). Doing a quick check, majoriy of the time taken was in mp_exptmod() routine with each call takes around 25 secs. I am running my processor(microblaze) at about 60mhz with hardware multipler, divider enabled. >From your knowledge, Is there any way to accelerate this in software or the only way to increase this is by hardware-acceleration? Thanx - Prasad On 7/17/06, Matt Johnston wrote: > On Mon, Jul 17, 2006 at 09:53:52PM -0700, Prasad wrote: > > Hi matt, > > Thanx for the response. I changed as u suggested and put dummy > > password authentication and it worked. > > > > Now i have a question. Actually the commandline interpreter i call has > > its own username and password authentication (which doesn't use > > /etc/passwd). So now i want to totally skip the regular username and > > password in the SSH and directly call my commandline interpreter > > (which has a password autentication by itself). How do i achieve that? > > Is there any security flaws in this kinda design. > > Something like the patch below should work for setting a > hardcoded user and allowing authentication immediately. > > I think it should be secure, as long as you make sure that > you're ignoring requests for different commands from the > user (which will get passed as arguments to your > interpreter), and your interpreter itself is secure. > > Matt > > > # > # old_revision [b59d9b3648d8fc72e8702a1013a1c6926d46ab2e] > # > # patch "svr-auth.c" > # from [dbd28ab1fff172ca3f2e4cb756ec53b74b48b6b3] > # to [2bf6cc2b096ba97f0614119414b9cd25a73fddfb] > # > ============================================================ > --- svr-auth.c dbd28ab1fff172ca3f2e4cb756ec53b74b48b6b3 > +++ svr-auth.c 2bf6cc2b096ba97f0614119414b9cd25a73fddfb > @@ -108,7 +108,10 @@ > } > > > - username = buf_getstring(ses.payload, &userlen); > + /* fake the username */ > + username = m_strdup("matt"); > + buf_eatstring(ses.payload); > + > servicename = buf_getstring(ses.payload, &servicelen); > methodname = buf_getstring(ses.payload, &methodlen); > > @@ -134,52 +137,16 @@ > } > > /* check username is good before continuing */ > - if (checkusername(username, userlen) == DROPBEAR_FAILURE) { > + if (checkusername(username, strlen(username)) == DROPBEAR_FAILURE) { > /* username is invalid/no shell/etc - send failure */ > TRACE(("sending checkusername failure")) > send_msg_userauth_failure(0, 1); > goto out; > } > > -#ifdef ENABLE_SVR_PASSWORD_AUTH > - if (!svr_opts.noauthpass && > - !(svr_opts.norootpass && ses.authstate.pw->pw_uid == 0) ) { > - /* user wants to try password auth */ > - if (methodlen == AUTH_METHOD_PASSWORD_LEN && > - strncmp(methodname, AUTH_METHOD_PASSWORD, > - AUTH_METHOD_PASSWORD_LEN) == 0) { > - svr_auth_password(); > - goto out; > - } > - } > -#endif > - > -#ifdef ENABLE_SVR_PAM_AUTH > - if (!svr_opts.noauthpass && > - !(svr_opts.norootpass && ses.authstate.pw->pw_uid == 0) ) { > - /* user wants to try password auth */ > - if (methodlen == AUTH_METHOD_PASSWORD_LEN && > - strncmp(methodname, AUTH_METHOD_PASSWORD, > - AUTH_METHOD_PASSWORD_LEN) == 0) { > - svr_auth_pam(); > - goto out; > - } > - } > -#endif > - > -#ifdef ENABLE_SVR_PUBKEY_AUTH > - /* user wants to try pubkey auth */ > - if (methodlen == AUTH_METHOD_PUBKEY_LEN && > - strncmp(methodname, AUTH_METHOD_PUBKEY, > - AUTH_METHOD_PUBKEY_LEN) == 0) { > - svr_auth_pubkey(); > - goto out; > - } > -#endif > - > - /* nothing matched, we just fail */ > - send_msg_userauth_failure(0, 1); > - > + /* allow login */ > + dropbear_log(LOG_NOTICE, "fake auth succeeded from %s", svr_ses.addrstring); > + send_msg_userauth_success(); > out: > > m_free(username); > > From matt at ucc.asn.au Wed Jul 19 10:47:19 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 19 Jul 2006 10:47:19 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh. In-Reply-To: <20060718060049.GM28731@ucc.gu.uwa.edu.au> References: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> <20060715022553.GB12898@ucc.gu.uwa.edu.au> <3351bfbe0607172153l2017b295j69d8b3f3156db35a@mail.gmail.com> <20060718060049.GM28731@ucc.gu.uwa.edu.au> Message-ID: <20060719024719.GI28731@ucc.gu.uwa.edu.au> On Tue, Jul 18, 2006 at 02:00:49PM +0800, Matt Johnston wrote: > On Mon, Jul 17, 2006 at 09:53:52PM -0700, Prasad wrote: > > So now i want to totally skip the regular username and > > password in the SSH and directly call my commandline interpreter > > (which has a password autentication by itself). How do i achieve that? > > Is there any security flaws in this kinda design. > I think it should be secure, as long as you make sure that > you're ignoring requests for different commands from the > user (which will get passed as arguments to your > interpreter), and your interpreter itself is secure. Another thought, you should probably disable any forwarding. TCP forwarding certainly could present a hazard (tunnel through the device to get around firewalls), and agent or X11 forwarding might have unforseen issues too. You might also be vulnerable to denial-of-service type issues, as someone could open numerous connections, each spawning an interpreter. One solution to that is to limit the total number of connections - see the thread http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2006q2/000388.html or your inetd implementation if you're using that. Matt From matt at ucc.asn.au Thu Jul 20 00:52:09 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 20 Jul 2006 00:52:09 +0800 Subject: Dropbear calling my own command-line parser than /bin/sh. In-Reply-To: <3351bfbe0607181853l5b18658mcf5fe16a1856dc37@mail.gmail.com> References: <3351bfbe0607141813m4ad5144ese567505bf9ed845@mail.gmail.com> <20060715022553.GB12898@ucc.gu.uwa.edu.au> <3351bfbe0607172153l2017b295j69d8b3f3156db35a@mail.gmail.com> <20060718060049.GM28731@ucc.gu.uwa.edu.au> <3351bfbe0607181853l5b18658mcf5fe16a1856dc37@mail.gmail.com> Message-ID: <20060719165209.GM28731@ucc.gu.uwa.edu.au> On Tue, Jul 18, 2006 at 06:53:18PM -0700, Prasad wrote: > The only problem now i have is that the entire process is really slow > until i get the login. I takes about 90 secs for me to get the shell. > (With or with-out the changes for my own interpreter). After i get > login everything is pretty fast. The size of the SSH key is 1024 bit. > (512 bytes reduces the time by about 60 secs). > > Doing a quick check, majoriy of the time taken was in mp_exptmod() > routine with each call takes around 25 secs. I am running my > processor(microblaze) at about 60mhz with hardware multipler, divider > enabled. > > >From your knowledge, Is there any way to accelerate this in software > or the only way to increase this is by hardware-acceleration? Using a DSS hostkey might be faster than RSA, you could try that. I assume you're already compling with -O2 (or whatever works for your platform) - that can make a big difference. Aside from that, I'm not really sure. Looking at a faster math library (or optimising LibTomCrypt) could be an option. It looks as if TomsFastMath might be a fairly easy replacement, though I'm not sure how portable or mature that is. Cheers, Matt From kmw1 at free.net.nz Fri Jul 21 14:57:30 2006 From: kmw1 at free.net.nz (Karl.) Date: Fri, 21 Jul 2006 18:57:30 +1200 Subject: dropbear & rssh chroot Message-ID: <20060721065730.GB32249@localhost.localdomain> I've recently been setting up a rssh chroot for securely 'sharing' some files via sftp - it's working fine with openssh, but I haven't yet got it going with dropbear. I've not found any references on the web to anyone using rssh with dropbear. I wondered if anyone here knows if it is possible to make it work or not (I've also asked on the rssh list). If it's likely to work, I'll try harder to make it go - I hate running daemons that are bigger than I need. thanks, Karl. From matt at ucc.asn.au Fri Jul 21 15:06:10 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 21 Jul 2006 15:06:10 +0800 Subject: dropbear & rssh chroot In-Reply-To: <20060721065730.GB32249@localhost.localdomain> References: <20060721065730.GB32249@localhost.localdomain> Message-ID: <20060721070610.GT28731@ucc.gu.uwa.edu.au> On Fri, Jul 21, 2006 at 06:57:30PM +1200, Karl. wrote: > I've recently been setting up a rssh chroot for securely 'sharing' some > files via sftp - it's working fine with openssh, but I haven't yet got > it going with dropbear. > > I've not found any references on the web to anyone using rssh with > dropbear. I wondered if anyone here knows if it is possible to make it > work or not (I've also asked on the rssh list). If it's likely to work, > I'll try harder to make it go - I hate running daemons that are bigger > than I need. I can't think of any intrinsic reason why it shouldn't work though I haven't looked that closely at how rssh works. Does it fail with a particular error message? Matt From kmw1 at free.net.nz Fri Jul 21 15:09:36 2006 From: kmw1 at free.net.nz (Karl.) Date: Fri, 21 Jul 2006 19:09:36 +1200 Subject: dropbear & rssh chroot In-Reply-To: <20060721070610.GT28731@ucc.gu.uwa.edu.au> References: <20060721065730.GB32249@localhost.localdomain> <20060721070610.GT28731@ucc.gu.uwa.edu.au> Message-ID: <20060721070936.GA1094@localhost.localdomain> Hi Matt, > I can't think of any intrinsic reason why it shouldn't work > though I haven't looked that closely at how rssh works. > Does it fail with a particular error message? I don't recall the exact error message at the moment, and won't be able to test until next week, but your reply is enough encouragement that I will look into it again and let you know when I have the information... thanks :-) Karl. From kmw1 at free.net.nz Thu Jul 27 13:05:47 2006 From: kmw1 at free.net.nz (Karl.) Date: Thu, 27 Jul 2006 17:05:47 +1200 Subject: dropbear & rssh chroot In-Reply-To: <20060721070610.GT28731@ucc.gu.uwa.edu.au> References: <20060721065730.GB32249@localhost.localdomain> <20060721070610.GT28731@ucc.gu.uwa.edu.au> Message-ID: <20060727050547.GA3062@localhost.localdomain> On Fri, Jul 21, 2006 at 03:06:10PM +0800, Matt Johnston wrote: > On Fri, Jul 21, 2006 at 06:57:30PM +1200, Karl. wrote: > > I've recently been setting up a rssh chroot for securely 'sharing' some > > files via sftp - it's working fine with openssh, but I haven't yet got > > it going with dropbear. > > I can't think of any intrinsic reason why it shouldn't work > though I haven't looked that closely at how rssh works. > Does it fail with a particular error message? OK. After the encouragement of being told it should work, I managed to find the problem while gathering the documentation for my "Why doesn't it work?" email :-) Here's the relevant info: Right now I'm running a dropbear server on one port and an openssh one on another port. Both are nonstandard port numbers. Both daemons are working for ssh shell logins. I only allow public key auth, with the relevant key loaded into ssh-agent. Running Debian Testing with dropbear 0.48.1-1 and openssh 1:4.3p2-2 ==== on the openssh port: $ sftp -o Port=44444 lsa at 192.168.1.6 Connecting to 192.168.1.6... sftp> ==== on the dropbear port: $ sftp -o Port=33333 lsa at 192.168.1.6 Connecting to 192.168.1.6... This account is restricted by rssh. Allowed commands: sftp If you believe this is in error, please contact your system administrator. Connection closed ==== syslog for openssh attempt shows: Jul 27 16:02:06 localhost rssh[5305]: setting log facility to LOG_USER Jul 27 16:02:06 localhost rssh[5305]: allowing sftp to all users Jul 27 16:02:06 localhost rssh[5305]: setting umask to 022 Jul 27 16:02:06 localhost rssh[5305]: chrooting all users to /home/chroot Jul 27 16:02:06 localhost rssh[5305]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper 2 "/usr/lib/openssh/sftp-server" Jul 27 16:02:06 localhost rssh_chroot_helper[5305]: new session for lsa, UID=1023 Jul 27 16:02:06 localhost rssh_chroot_helper[5305]: user's home dir is /home/chroot/lsa Jul 27 16:02:06 localhost rssh_chroot_helper[5305]: chrooted to /home/chroot Jul 27 16:02:07 localhost rssh_chroot_helper[5305]: changing working directory to /lsa (inside jail) ==== syslog for dropbear attempt shows: Jul 27 16:03:53 localhost rssh[6017]: setting log facility to LOG_USER Jul 27 16:03:53 localhost rssh[6017]: allowing sftp to all users Jul 27 16:03:53 localhost rssh[6017]: setting umask to 022 Jul 27 16:03:54 localhost rssh[6017]: chrooting all users to /home/chroot Jul 27 16:03:54 localhost rssh[6017]: user lsa attempted to execute forbidden commands Jul 27 16:03:54 localhost rssh[6017]: command: /usr/lib/sftp-server ==== Paying attention to the logs, I see that dropbear is trying to call the sftp-server at usr/lib/ whilst openssh is calling it at usr/lib/openssh/ - one is symlinked to the other, and that would be fine in normal circumstance, but obviously it's not going to be acceptable to rssh! Changing my sftp invocation to specify the rssh-compliant path yields the happy result: $ sftp -o Port=33333 -s /usr/lib/openssh/sftp-server lsa at 192.168.1.6 Connecting to 192.168.1.6... sftp> So, I can connect from the command-line now. :-) The remaining problem is when I try to connect using WinSCP or Tunnelier (the main purpose of this rssh chroot is to allow restricted access for an untrusted Windows box) - these gui tools don't allow me to specify a path for sftp-server. I imagine I will need to recompile dropbear with the altered path - I have a faint recollection of reading something about Debian having changed some openssh paths as part of the packaging setup. Thank you, Matt, for your encouragement and for writing dropbear :-) Karl. From matt at ucc.asn.au Thu Jul 27 13:35:47 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 27 Jul 2006 13:35:47 +0800 Subject: dropbear & rssh chroot In-Reply-To: <20060727050547.GA3062@localhost.localdomain> References: <20060721065730.GB32249@localhost.localdomain> <20060721070610.GT28731@ucc.gu.uwa.edu.au> <20060727050547.GA3062@localhost.localdomain> Message-ID: <20060727053547.GN4434@ucc.gu.uwa.edu.au> On Thu, Jul 27, 2006 at 05:05:47PM +1200, Karl. wrote: > OK. After the encouragement of being told it should work, I managed to > find the problem while gathering the documentation for my "Why doesn't > it work?" email :-) > > Here's the relevant info: > syslog for openssh attempt shows: > Jul 27 16:02:06 localhost rssh[5305]: chroot cmd line: /usr/lib/rssh/rssh_chroot_helper 2 "/usr/lib/openssh/sftp-server" > ==== > syslog for dropbear attempt shows: > Jul 27 16:03:54 localhost rssh[6017]: user lsa attempted to execute forbidden commands > Jul 27 16:03:54 localhost rssh[6017]: command: /usr/lib/sftp-server > I imagine I will need to recompile dropbear with the altered path - I > have a faint recollection of reading something about Debian having > changed some openssh paths as part of the packaging setup. There's a SFTPSERVER_PATH setting in options.h that changes this. Unfortunately the path seems to vary a fair bit between systems. You might be able to work around the issue by changing the symlink to a hardlink, and modifying rssh's config file to allow the /usr/lib/sftp-server path. Matt From hcegtvedt at atmel.com Thu Aug 3 22:18:44 2006 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Thu, 03 Aug 2006 16:18:44 +0200 Subject: Hash mismatch when SSHing to dropbear server Message-ID: <44D205C4.8060000@atmel.com> Hi I've compiled dropbear for the avr32 platform, the compilation goes about without any problems, although there is alot of "differ in signedness" warnings. The problem is that it works fine ssh'ing from the avr32 => avr32, but I can't ssh from my workstation (Intel P4 running Ubuntu Dapper). Could the hash mismatch openssh reports on my workstation be related to a big-endian vs. little-endian bug/issue in the dropbear software? The avr32 is big-endian. Debug from ssh to the avr32 running dropbear 0.48.1. debug1: Remote protocol version 2.0, remote software version dropbear_0.48 debug1: no match: dropbear_0.48 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: sending SSH2_MSG_KEXDH_INIT debug1: expecting SSH2_MSG_KEXDH_REPLY The authenticity of host '10.191.252.83 (10.191.252.83)' can't be established. RSA key fingerprint is 3b:26:ee:d2:5b:5b:ba:5d:07:37:f2:4c:89:67:ba:14. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.191.252.83' (RSA) to the list of known hosts. hash mismatch debug1: ssh_rsa_verify: signature incorrect key_verify failed for server_host_key Syslog on the avr32 running dropbear: Aug 3 14:07:39 10 authpriv.info dropbear[571]: Child connection from 10.191.252.128:37507 Aug 3 14:07:43 10 authpriv.info dropbear[571]: exit before auth: error reading: Connection reset by peer The same applies if I use a dss key. Any hints or tips to where I should start attacking would be great (-: -- With kind regards, Med vennlig hilsen, Hans-Christian Egtvedt Applications Engineer - AVR Applications Lab Atmel Norway From matt at ucc.asn.au Fri Aug 4 13:40:28 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 4 Aug 2006 13:40:28 +0800 Subject: Hash mismatch when SSHing to dropbear server In-Reply-To: <44D205C4.8060000@atmel.com> References: <44D205C4.8060000@atmel.com> Message-ID: <20060804054028.GT15998@ucc.gu.uwa.edu.au> On Thu, Aug 03, 2006 at 04:18:44PM +0200, Hans-Christian Egtvedt wrote: > I've compiled dropbear for the avr32 platform, the compilation goes > about without any problems, although there is alot of "differ in > signedness" warnings. > > The problem is that it works fine ssh'ing from the avr32 => avr32, but I > can't ssh from my workstation (Intel P4 running Ubuntu Dapper). > > Could the hash mismatch openssh reports on my workstation be related to > a big-endian vs. little-endian bug/issue in the dropbear software? > The avr32 is big-endian. > hash mismatch > debug1: ssh_rsa_verify: signature incorrect > key_verify failed for server_host_key > The same applies if I use a dss key. > Any hints or tips to where I should start attacking would be great (-: The error suggests that something is going wrong in the big-number code (libtommath) - I don't _think_ it's just a wrong-endianness issue. A first thing to try might be compiling with -O0 or -O2 (rather than -Os as the default?), and also trying -fno-strict-aliasing. You could also try setting MP_16BIT at the top of libtommath/tommath.h - that shouldn't make a difference, but it's worth checking. Let me know how it goes, if those don't help I'll have a look further. Matt From hcegtvedt at atmel.com Fri Aug 4 16:09:08 2006 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Fri, 04 Aug 2006 10:09:08 +0200 Subject: Hash mismatch when SSHing to dropbear server In-Reply-To: <20060804054028.GT15998@ucc.gu.uwa.edu.au> References: <44D205C4.8060000@atmel.com> <20060804054028.GT15998@ucc.gu.uwa.edu.au> Message-ID: <44D300A4.3070205@atmel.com> Matt Johnston wrote: > On Thu, Aug 03, 2006 at 04:18:44PM +0200, Hans-Christian Egtvedt wrote: >> I've compiled dropbear for the avr32 platform, the compilation goes >> about without any problems, although there is alot of "differ in >> signedness" warnings. >> >> The problem is that it works fine ssh'ing from the avr32 => avr32, but I >> can't ssh from my workstation (Intel P4 running Ubuntu Dapper). >> >> Could the hash mismatch openssh reports on my workstation be related to >> a big-endian vs. little-endian bug/issue in the dropbear software? >> The avr32 is big-endian. > >> hash mismatch >> debug1: ssh_rsa_verify: signature incorrect >> key_verify failed for server_host_key > >> The same applies if I use a dss key. > >> Any hints or tips to where I should start attacking would be great (-: > > The error suggests that something is going wrong in the > big-number code (libtommath) - I don't _think_ it's just a > wrong-endianness issue. A first thing to try might be > compiling with -O0 or -O2 (rather than -Os as the default?), > and also trying -fno-strict-aliasing. I tried most combinations, but they don't effect the result. > You could also try setting MP_16BIT at the top of > libtommath/tommath.h - that shouldn't make a difference, but > it's worth checking. Didn't do anything good. > Let me know how it goes, if those don't help I'll have a > look further. FWIIW: : root at 10 / # dbclient workstation -l user dbclient: connection to user at workstation:22 exited: Bad hostkey signature : root at 10 / # dbclient localhost Host 'localhost' is not in the trusted hosts file. (fingerprint md5 2a:8f:df:71:95:ed:ea:50:4a:fa:16:00:b1:47:c7:22) Do you want to continue connecting? (y/n) y Password: : root at 10 / # So the error corrects it self when I ssh localhost, but external targets is a no-go. Could this be an alligment error? -- With kind regards, Med vennlig hilsen, Hans-Christian Egtvedt Applications Engineer - AVR Applications Lab Atmel Norway From matt at ucc.asn.au Mon Aug 7 00:07:27 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 7 Aug 2006 00:07:27 +0800 Subject: Hash mismatch when SSHing to dropbear server In-Reply-To: <44D300A4.3070205@atmel.com> References: <44D205C4.8060000@atmel.com> <20060804054028.GT15998@ucc.gu.uwa.edu.au> <44D300A4.3070205@atmel.com> Message-ID: <20060806160726.GL6519@ucc.gu.uwa.edu.au> On Fri, Aug 04, 2006 at 10:09:08AM +0200, Hans-Christian Egtvedt wrote: > So the error corrects it self when I ssh localhost, but external targets > is a no-go. > > Could this be an alligment error? Possibly? To try and figure what's going on, I've put a version with some copius debugging of the RSA bits at http://matt.ucc.asn.au/dropbear/testing/db-unrandom1.tar.gz The random number generator has been made totally deterministic, so subsequent runs on different hosts can be compared. Compile the server binary for your workstation and compile the client for both the avr32 and the workstation. Run the server on your workstation using the included "constant_rsa" key - then I can compare what I'm seeing. You might want to run it with "2> /dev/null" as it'll print a lot of junk. Then run the debugging client both on the avr32 and your workstation, as "./dbclient -v workstation 2> logfile". If it's working correctly, you should see mostly the same output on each host (I've put a copy of what I see in that website dir). If it seems to hang for ages before showing a password prompt, you might need to press "y" for the hidden key confirmation prompt. I'm guessing that you'll probably see different big-number output on the avr32, which might help narrow things down. I'm not entirely sure what to be looking for, but with some extra dropbear_trace() and print_mp_int() calls in libtommath/bn_mp_exptmod_fast.c it should be possible to narrow down the differences to a particular bit of code. Hopefully that might be of use. Cheers, Matt From hcegtvedt at atmel.com Mon Aug 7 15:54:30 2006 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Mon, 07 Aug 2006 09:54:30 +0200 Subject: Hash mismatch when SSHing to dropbear server In-Reply-To: <20060806160726.GL6519@ucc.gu.uwa.edu.au> References: <44D205C4.8060000@atmel.com> <20060804054028.GT15998@ucc.gu.uwa.edu.au> <44D300A4.3070205@atmel.com> <20060806160726.GL6519@ucc.gu.uwa.edu.au> Message-ID: <44D6F1B6.4060508@atmel.com> Matt Johnston wrote: > On Fri, Aug 04, 2006 at 10:09:08AM +0200, Hans-Christian Egtvedt wrote: > >> So the error corrects it self when I ssh localhost, but external targets >> is a no-go. >> >> Could this be an alligment error? > > Possibly? To try and figure what's going on, I've put a > version with some copius debugging of the RSA bits at > http://matt.ucc.asn.au/dropbear/testing/db-unrandom1.tar.gz > The random number generator has been made totally > deterministic, so subsequent runs on different hosts can be > compared. Thanks for your help so far with this problem, but I can't seem to be able to download the files. I get a 403 access denied. Let me know when you've changed the access, and I'll give it a shot (-: -- With kind regards, Med vennlig hilsen, Hans-Christian Egtvedt Applications Engineer - AVR Applications Lab Atmel Norway From pgf at brightstareng.com Mon Aug 7 21:17:15 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 07 Aug 2006 09:17:15 -0400 Subject: logging all activity? Message-ID: <14327.1154956635@brightstareng.com> hi -- is there a relatively painless way to cause the dropbear server to log all remote command executions? i only need this for debugging -- i want to see all instances where a client has run "ssh myhost some command", or has run scp to copy files to or from myhost. i don't need interactive session logging. a quick perusal of the docs didn't turn up anything obvious. thanks, paul =--------------------- paul fox, pgf at brightstareng.com From matt at ucc.asn.au Mon Aug 7 21:40:47 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 7 Aug 2006 21:40:47 +0800 Subject: logging all activity? In-Reply-To: <14327.1154956635@brightstareng.com> References: <14327.1154956635@brightstareng.com> Message-ID: <20060807134047.GL6519@ucc.gu.uwa.edu.au> On Mon, Aug 07, 2006 at 09:17:15AM -0400, Paul Fox wrote: > hi -- is there a relatively painless way to cause the dropbear > server to log all remote command executions? i only need this > for debugging -- i want to see all instances where a client has > run "ssh myhost some command", or has run scp to copy files to or > from myhost. i don't need interactive session logging. > > a quick perusal of the docs didn't turn up anything obvious. There's no builtin way, though you could modify a shell login file (.zshenv for zsh, not sure about others) to log the commands, since all commands are actually run as 'sh -c "some command"'. The attached patch will work if you don't mind recompiling. Matt --- options.h c365717890e92696dd8e3f5821531993ec37ff35 +++ options.h 5b1911f76acd50bba2503c24654c9194299cb022 @@ -199,8 +199,10 @@ etc) slower (perhaps by 50%). Recommende * not using the Dropbear client, you'll need to change it */ #define _PATH_SSH_PROGRAM "/usr/bin/dbclient" -/* Multi-purpose binary configuration has now moved. Look at the top - * of the Makefile for instructions, or INSTALL */ +/* Whether to log commands executed by a client. This only logs the + * (single) command sent to the server, not what a user did in a + * shell/sftp session etc. */ +#define LOG_COMMANDS /******************************************************************* * You shouldn't edit below here unless you know you need to. ============================================================ --- svr-chansession.c d64917b0372fdb027e8704c9504cc4c2ed787398 +++ svr-chansession.c a89352777afb63df597fa6790c6c079fbbb67737 @@ -588,6 +588,16 @@ static int sessioncommand(struct Channel } } +#ifdef LOG_COMMANDS + if (chansess->cmd) { + dropbear_log(LOG_INFO, "user %s executing '%s'", + ses.authstate.printableuser, chansess->cmd); + } else { + dropbear_log(LOG_INFO, "user %s executing login shell", + ses.authstate.printableuser); + } +#endif + if (chansess->term == NULL) { /* no pty */ ret = noptycommand(channel, chansess); From pgf at brightstareng.com Mon Aug 7 22:28:13 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 07 Aug 2006 10:28:13 -0400 Subject: logging all activity? In-Reply-To: matt's message of Mon, 07 Aug 2006 21:40:47 +0800. <20060807134047.GL6519@ucc.gu.uwa.edu.au> Message-ID: <15999.1154960893@brightstareng.com> matt wrote: > On Mon, Aug 07, 2006 at 09:17:15AM -0400, Paul Fox wrote: > > hi -- is there a relatively painless way to cause the dropbear > > server to log all remote command executions? i only need this > > for debugging -- i want to see all instances where a client has > > run "ssh myhost some command", or has run scp to copy files to or > > from myhost. i don't need interactive session logging. > > > > a quick perusal of the docs didn't turn up anything obvious. > > There's no builtin way, though you could modify a shell > login file (.zshenv for zsh, not sure about others) to log > the commands, since all commands are actually run as > 'sh -c "some command"'. oh, good idea. i'll try that first. > > The attached patch will work if you don't mind recompiling. excellent! thanks, paul =--------------------- paul fox, pgf at brightstareng.com From rob at landley.net Tue Aug 8 08:28:02 2006 From: rob at landley.net (Rob Landley) Date: Mon, 7 Aug 2006 20:28:02 -0400 Subject: logging all activity? In-Reply-To: <20060807134047.GL6519@ucc.gu.uwa.edu.au> References: <14327.1154956635@brightstareng.com> <20060807134047.GL6519@ucc.gu.uwa.edu.au> Message-ID: <200608072028.03066.rob@landley.net> On Monday 07 August 2006 9:40 am, Matt Johnston wrote: > On Mon, Aug 07, 2006 at 09:17:15AM -0400, Paul Fox wrote: > > hi -- is there a relatively painless way to cause the dropbear > > server to log all remote command executions? i only need this > > for debugging -- i want to see all instances where a client has > > run "ssh myhost some command", or has run scp to copy files to or > > from myhost. i don't need interactive session logging. > > > > a quick perusal of the docs didn't turn up anything obvious. > > There's no builtin way, though you could modify a shell > login file (.zshenv for zsh, not sure about others) to log > the commands, since all commands are actually run as > 'sh -c "some command"'. Just confirming: They're run with the shell for the user in the /etc/passwd file, right? So you can stick any kind of gatekeeper program you want in there. (Did that on openssh long ago...) So an easy way to do this is make a special user whose login shell is a logging wrapper thing. Rob -- Never bet against the cheap plastic solution. From matt at ucc.asn.au Tue Aug 8 10:32:41 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 8 Aug 2006 10:32:41 +0800 Subject: logging all activity? In-Reply-To: <200608072028.03066.rob@landley.net> References: <14327.1154956635@brightstareng.com> <20060807134047.GL6519@ucc.gu.uwa.edu.au> <200608072028.03066.rob@landley.net> Message-ID: <20060808023241.GR6519@ucc.gu.uwa.edu.au> On Mon, Aug 07, 2006 at 08:28:02PM -0400, Rob Landley wrote: > Just confirming: > > They're run with the shell for the user in the /etc/passwd file, right? So > you can stick any kind of gatekeeper program you want in there. (Did that on > openssh long ago...) Yes, the /etc/passwd shell (or /bin/sh if it's blank). Cheers, Matt From pgf at brightstareng.com Tue Aug 8 10:45:11 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 07 Aug 2006 22:45:11 -0400 Subject: logging all activity? In-Reply-To: rob's message of Mon, 07 Aug 2006 20:28:02 -0400. <200608072028.03066.rob@landley.net> Message-ID: <3326.1155005111@brightstareng.com> rob wrote: > On Monday 07 August 2006 9:40 am, Matt Johnston wrote: > > On Mon, Aug 07, 2006 at 09:17:15AM -0400, Paul Fox wrote: > > > hi -- is there a relatively painless way to cause the dropbear > > > server to log all remote command executions? i only need this ... > > > a quick perusal of the docs didn't turn up anything obvious. > > > > There's no builtin way, though you could modify a shell > > login file (.zshenv for zsh, not sure about others) to log > > the commands, since all commands are actually run as > > 'sh -c "some command"'. > > Just confirming: > > They're run with the shell for the user in the /etc/passwd file, right? So > you can stick any kind of gatekeeper program you want in there. (Did that on > openssh long ago...) > > So an easy way to do this is make a special user whose login shell is a > logging wrapper thing. another good idea -- thanks. putting a logging line in .profile didn't work right off the bat, so i applied matt's patch and it did the trick. it occurred to me that .profile might not necessarily be read for "sh -c" kinds of things. the wrapper idea clearly would have worked. paul =--------------------- paul fox, pgf at brightstareng.com From hcegtvedt at atmel.com Tue Aug 8 16:59:15 2006 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Tue, 08 Aug 2006 10:59:15 +0200 Subject: Hash mismatch when SSHing to dropbear server In-Reply-To: <20060806160726.GL6519@ucc.gu.uwa.edu.au> References: <44D205C4.8060000@atmel.com> <20060804054028.GT15998@ucc.gu.uwa.edu.au> <44D300A4.3070205@atmel.com> <20060806160726.GL6519@ucc.gu.uwa.edu.au> Message-ID: <44D85263.8070107@atmel.com> Matt Johnston wrote: > On Fri, Aug 04, 2006 at 10:09:08AM +0200, Hans-Christian Egtvedt wrote: > >> So the error corrects it self when I ssh localhost, but external targets >> is a no-go. >> >> Could this be an alligment error? > > Possibly? To try and figure what's going on, I've put a > version with some copius debugging of the RSA bits at > http://matt.ucc.asn.au/dropbear/testing/db-unrandom1.tar.gz > The random number generator has been made totally > deterministic, so subsequent runs on different hosts can be > compared. > > Compile the server binary for your workstation and compile > the client for both the avr32 and the workstation. Run the > server on your workstation using the included "constant_rsa" > key - then I can compare what I'm seeing. You might want to > run it with "2> /dev/null" as it'll print a lot of junk. Done > Then run the debugging client both on the avr32 and your > workstation, as "./dbclient -v workstation 2> logfile". > If it's working correctly, you should see mostly the same > output on each host (I've put a copy of what I see in that > website dir). If it seems to hang for ages before showing a > password prompt, you might need to press "y" for the hidden > key confirmation prompt. You were right about the confirmation prompt > I'm guessing that you'll probably see different big-number > output on the avr32, which might help narrow things down. > I'm not entirely sure what to be looking for, but with some > extra dropbear_trace() and print_mp_int() calls in > libtommath/bn_mp_exptmod_fast.c it should be possible to > narrow down the differences to a particular bit of code. I put the logs here: http://www.egtvedt.no/dropbear/ > Hopefully that might be of use. I'm not quite seeing what I should be looking for, if anybody have a pointer to what I should see (correct calculations etc) then I can start my debugging :) -- With kind regards, Med vennlig hilsen, Hans-Christian Egtvedt Applications Engineer - AVR Applications Lab Atmel Norway From yan at seiner.com Sat Aug 12 01:27:15 2006 From: yan at seiner.com (Yan Seiner) Date: Fri, 11 Aug 2006 10:27:15 -0700 Subject: keys generated on one architecture for another? Message-ID: <44DCBDF3.1060307@seiner.com> I have dropbear compiled for arm. I've run it before with no problems, but now I am running into an issue... In the test system I built a native dropbearkeys and built the keys on the arm board. In the production system I was hoping to pre-build the keys on the x86 build host; when I do that I get: / # /bin/dropbear -F -v TRACE: enter loadhostkeys [1154] Jan 01 00:30:22 premature exit: bad buf_incrwritepos: BUF_MAX_INCR TRACE: enter session_cleanup TRACE: leave session_cleanup: !sessinitdone I've modified the source to tell me which if condition is failing.... And it is the max increment, which is defined to be a very large number.... So are the keys architecture specific? Am I running into some integer length or *-endian issues here? Can you pre-build keys on an x86 for arm? Thanks --Yan From matt at ucc.asn.au Sat Aug 12 14:56:50 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 12 Aug 2006 14:56:50 +0800 Subject: keys generated on one architecture for another? In-Reply-To: <44DCBDF3.1060307@seiner.com> References: <44DCBDF3.1060307@seiner.com> Message-ID: <20060812065650.GX30226@ucc.gu.uwa.edu.au> On Fri, Aug 11, 2006 at 10:27:15AM -0700, Yan Seiner wrote: > / # /bin/dropbear -F -v > TRACE: enter loadhostkeys > [1154] Jan 01 00:30:22 premature exit: bad buf_incrwritepos: BUF_MAX_INCR > TRACE: enter session_cleanup > TRACE: leave session_cleanup: !sessinitdone > > I've modified the source to tell me which if condition is failing.... > And it is the max increment, which is defined to be a very large number.... > > So are the keys architecture specific? Am I running into some integer > length or *-endian issues here? > > Can you pre-build keys on an x86 for arm? They keys should work fine between platforms. Could you send a sample key generated on each platform? Cheers, Matt From yan at seiner.com Wed Aug 16 18:41:49 2006 From: yan at seiner.com (Yan Seiner) Date: Wed, 16 Aug 2006 03:41:49 -0700 Subject: keys generated on one architecture for another? In-Reply-To: References: Message-ID: <44E2F66D.7090205@seiner.com> >Date: Sat, 12 Aug 2006 14:56:50 +0800 >From: Matt Johnston >Subject: Re: keys generated on one architecture for another? >To: Yan Seiner >Cc: dropbear at ucc.asn.au >Message-ID: <20060812065650.GX30226 at ucc.gu.uwa.edu.au> >Content-Type: text/plain; charset=us-ascii > >On Fri, Aug 11, 2006 at 10:27:15AM -0700, Yan Seiner wrote: > > >>/ # /bin/dropbear -F -v >>TRACE: enter loadhostkeys >>[1154] Jan 01 00:30:22 premature exit: bad buf_incrwritepos: BUF_MAX_INCR >>TRACE: enter session_cleanup >>TRACE: leave session_cleanup: !sessinitdone >> >>I've modified the source to tell me which if condition is failing.... >>And it is the max increment, which is defined to be a very large number.... >> >>So are the keys architecture specific? Am I running into some integer >>length or *-endian issues here? >> >>Can you pre-build keys on an x86 for arm? >> >> > >They keys should work fine between platforms. Could you send >a sample key generated on each platform? > > Matt: I finally got around to figuring out what was going on, and I have an issue that may be a bug/security issue/lack of understanding on my part... First of all, by way of background, my target file system is generated by an ordinary user, UID 1000, GID 1000. This is OK for most apps; I change the perms on busybox to make it happy. The dropbear keys are generated with UID 1000, GID 1000, and perms of 0600. craywb:/home/local/panel/arm/ts7200/etc/dropbear# ls -l total 8 -rw------- 1 yan yan 457 2006-04-06 16:14 dropbear_dss_host_key -rw------- 1 yan yan 427 2006-04-06 16:13 dropbear_rsa_host_key And dropbear fails with: open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 read(3, 0x2edf8, 1700) = -1 EIO (Input/output error) time(NULL) = 18 open("/etc/localtime", O_RDONLY) = -1 ENOENT (No such file or directory) getpid() = 68 write(2, "[68] Jan 01 00:00:18 premature e"..., 72[68] Jan 01 00:00:18 premature exit: bad buf_incrwritepos: BUF_R) = 72 _exit(1) = ? Now we change keys to be owned by root: craywb:/home/local/panel/arm/ts7200/etc/dropbear# ls -l total 8 -rw------- 1 root root 457 2006-04-06 16:14 dropbear_dss_host_key -rw------- 1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key and dropbear fails with: open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 read(3, 0x2edf8, 1700) = -1 EACCES (Permission denied) time(NULL) = 117 open("/etc/localtime", O_RDONLY) = -1 ENOENT (No such file or directory) getpid() = 71 write(2, "[71] Jan 01 00:01:57 premature e"..., 72[71] Jan 01 00:01:57 premature exit: bad buf_incrwritepos: BUF_R) = 72 _exit(1) So we change the perms to 644 and dropbear finally succeeds.... craywb:/home/local/panel/arm/ts7200/etc/dropbear# ls -l total 8 -rw-r--r-- 1 root root 457 2006-04-06 16:14 dropbear_dss_host_key -rw-r--r-- 1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 read(3, "\0\0\0\7ssh-rsa\0\0\0\3\1\0\1\0\0\0\203\0\300\234C\260"..., 1700) = 427 read(3, "", 1273) = 0 close(3) = 0 open("/etc/dropbear/dropbear_dss_host_key", O_RDONLY) = 3 read(3, "\0\0\0\7ssh-dss\0\0\0\201\0\2004\252 X\260g\330_1\352\253"..., 1700) = 457 read(3, "", 1243) = 0 close(3) = 0 brk(0) = 0x30000 brk(0x31000) = 0x31000 time(NULL) = 166 open("/etc/localtime", O_RDONLY) = -1 ENOENT (No such file or directory) getpid() = 73 write(2, "[73] Jan 01 00:02:46 Not forking"..., 33[73] Jan 01 00:02:46 Not forking ) = 33 open("/var/run/dropbear.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or directory) socket(PF_INET6, SOCK_STREAM, IPPROTO_TCP) = -1 EAFNOSUPPORT (Address family not supported by protocol) socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=1, linger=5}, 8) = 0 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0 setsockopt(3, SOL_SOCKET, SO_PRIORITY, [6], 4) = 0 bind(3, {sa_family=AF_INET, sin_port=htons(22), sin_addr=inet_addr("0.0.0.0")}, 16) = 0 listen(3, 20) Now I am really confused..... Shouldn't the keys be only readable by root? Shouldn't dropbear throw an error at world readable keys? And why would dropbear fail to read a file only readable by root when it is running with root perms? I didn't see anywhere in the strace logs that dropbear relinquished su priveledges, and it is run as root: / # ps PID Uid VmSize Stat Command 1 root 600 S init 2 root SW [keventd] 3 root SWN [ksoftirqd_CPU0] 4 root SW [kswapd] 5 root SW [bdflush] 6 root SW [kupdated] 7 root SW [mtdblockd] 8 root SW [rpciod] 24 root 676 S /bin/sh /etc/init.d/rcS 26 root 688 S /bin/sh /etc/init.d/rcS 48 root SW [khubd] 66 root 764 S /bin/hush 77 root 552 S dropbear 78 root 812 R /bin/hush / # dropbear --version Unknown argument --version Dropbear sshd v0.47 Thoughts? --Yan From matt at ucc.asn.au Thu Aug 17 10:59:36 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 17 Aug 2006 10:59:36 +0800 Subject: keys generated on one architecture for another? In-Reply-To: <44E2F66D.7090205@seiner.com> References: <44E2F66D.7090205@seiner.com> Message-ID: <20060817025936.GZ30226@ucc.gu.uwa.edu.au> On Wed, Aug 16, 2006 at 03:41:49AM -0700, Yan Seiner wrote: > I finally got around to figuring out what was going on, and I have an > issue that may be a bug/security issue/lack of understanding on my part... > -rw------- 1 yan yan 457 2006-04-06 16:14 dropbear_dss_host_key > -rw------- 1 yan yan 427 2006-04-06 16:13 dropbear_rsa_host_key > And dropbear fails with: > open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 > read(3, 0x2edf8, 1700) = -1 EIO (Input/output error) > -rw------- 1 root root 457 2006-04-06 16:14 dropbear_dss_host_key > -rw------- 1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key > and dropbear fails with: > open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 > read(3, 0x2edf8, 1700) = -1 EACCES (Permission denied) > So we change the perms to 644 and dropbear finally succeeds.... > -rw-r--r-- 1 root root 457 2006-04-06 16:14 dropbear_dss_host_key > -rw-r--r-- 1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key > open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 > read(3, "\0\0\0\7ssh-rsa\0\0\0\3\1\0\1\0\0\0\203\0\300\234C\260"..., > > Now I am really confused..... That really looks like there's something wrong at the OS/filesystem level? All the manpages I've looked at (Linux, Darwin, Tru64, Solaris) don't mention read() returning with EACCESS. I would've expected that to happen in the open() call. Even then root should be able to read it unless there's some unusual security setup? The EIO return should be handled better by Dropbear, though I don't think it's the correct return value from the OS (it should indicate a physical error)? I'll fix up the error checking in Dropbear's buf_readfile() function. > Shouldn't the keys be only readable by root? Shouldn't dropbear throw > an error at world readable keys? Possibly. dropbearkey generates them with mode 600, so if an admin chmods them, then they've hopefully done it intentionally... > I didn't see anywhere in the strace logs that dropbear relinquished su > priveledges, and it is run as root: Yep, the main server process runs as root. I guess this is a Linux variant from the ps listing. Which filesystem is it running? I suspect that's where the problem lies. Cheers, Matt From haseebq at gmail.com Thu Aug 17 19:10:59 2006 From: haseebq at gmail.com (Haseeb Abdul Qadir) Date: Thu, 17 Aug 2006 04:10:59 -0700 Subject: 'received data with bad writefd' Message-ID: <3534fd3a0608170410w4f2c0d3amcbf1f79f919b8bed@mail.gmail.com> Hi, When using dropbear for port forwarding only (no command shell, no pty) the sever sometimes unexpectedly exits with: [21929] Aug 17 06:29:01 exit after auth (haseebq): received data with bad writefd Its not a 100% repro but I have seen it happen a few times. Any idea how I'd diagnose this? Thanks, -Haseeb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060817/59856de5/attachment.html From yan at seiner.com Thu Aug 17 20:48:32 2006 From: yan at seiner.com (Yan Seiner) Date: Thu, 17 Aug 2006 05:48:32 -0700 Subject: keys generated on one architecture for another? In-Reply-To: <20060817025936.GZ30226@ucc.gu.uwa.edu.au> References: <44E2F66D.7090205@seiner.com> <20060817025936.GZ30226@ucc.gu.uwa.edu.au> Message-ID: <44E465A0.4050805@seiner.com> Matt Johnston wrote: > On Wed, Aug 16, 2006 at 03:41:49AM -0700, Yan Seiner wrote: > >> I finally got around to figuring out what was going on, and I have an >> issue that may be a bug/security issue/lack of understanding on my part... >> > > >> -rw------- 1 yan yan 457 2006-04-06 16:14 dropbear_dss_host_key >> -rw------- 1 yan yan 427 2006-04-06 16:13 dropbear_rsa_host_key >> And dropbear fails with: >> open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 >> read(3, 0x2edf8, 1700) = -1 EIO (Input/output error) >> > > >> -rw------- 1 root root 457 2006-04-06 16:14 dropbear_dss_host_key >> -rw------- 1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key >> and dropbear fails with: >> open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 >> read(3, 0x2edf8, 1700) = -1 EACCES (Permission denied) >> > > >> So we change the perms to 644 and dropbear finally succeeds.... >> -rw-r--r-- 1 root root 457 2006-04-06 16:14 dropbear_dss_host_key >> -rw-r--r-- 1 root root 427 2006-04-06 16:13 dropbear_rsa_host_key >> open("/etc/dropbear/dropbear_rsa_host_key", O_RDONLY) = 3 >> read(3, "\0\0\0\7ssh-rsa\0\0\0\3\1\0\1\0\0\0\203\0\300\234C\260"..., >> >> Now I am really confused..... >> > > That really looks like there's something wrong at the > OS/filesystem level? All the manpages I've looked at (Linux, > Darwin, Tru64, Solaris) don't mention read() returning with > EACCESS. I would've expected that to happen in the open() > call. Even then root should be able to read it unless > there's some unusual security setup? > The system is running glibc-2.3.2, and busybox 1.2.1. No unusual setup at all; basically a stock compile using a crosstool from kegel.com. The fs is hand-built by moving libs and executables to the target fs, and setting permissions as we go. There are two possibilites I can think of. One is a bug in busybox's nfs.... The target box (an arm board) is mounting the fs via nfs. The second is a missing library. I've done some spidering through the lib dependencies, and I think I have them all, but it is possible I am missing one. > The EIO return should be handled better by Dropbear, though > I don't think it's the correct return value from the OS (it > should indicate a physical error)? I'll fix up the error > checking in Dropbear's buf_readfile() function. > > >> I didn't see anywhere in the strace logs that dropbear relinquished su >> priveledges, and it is run as root: >> > > Yep, the main server process runs as root. > > I guess this is a Linux variant from the ps listing. Which > filesystem is it running? I suspect that's where the problem > lies. > I suspect there may be some issues between busybox 1.2.1 and my kernel as pertains to console handling.... I don't know if that's what I'm seeing here. I have an older, heavily patched version I used for development earlier on. I'll see if I can reproduce the problem with it. --Yan From matt at ucc.asn.au Thu Aug 17 21:18:46 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Thu, 17 Aug 2006 21:18:46 +0800 Subject: keys generated on one architecture for another? In-Reply-To: <44E465A0.4050805@seiner.com> References: <44E2F66D.7090205@seiner.com> <20060817025936.GZ30226@ucc.gu.uwa.edu.au> <44E465A0.4050805@seiner.com> Message-ID: <20060817131846.GJ30226@ucc.gu.uwa.edu.au> On Thu, Aug 17, 2006 at 05:48:32AM -0700, Yan Seiner wrote: > The system is running glibc-2.3.2, and busybox 1.2.1. No unusual setup > at all; basically a stock compile using a crosstool from kegel.com. The > fs is hand-built by moving libs and executables to the target fs, and > setting permissions as we go. > > There are two possibilites I can think of. One is a bug in busybox's > nfs.... The target box (an arm board) is mounting the fs via nfs. The > second is a missing library. I've done some spidering through the lib > dependencies, and I think I have them all, but it is possible I am > missing one. Aha, if it's over NFS, then the server wouldn't happen to have root_squash set in it's /etc/exports would it? That would explain the permission problems. Cheers, Matt From rob at landley.net Fri Aug 18 01:52:51 2006 From: rob at landley.net (Rob Landley) Date: Thu, 17 Aug 2006 13:52:51 -0400 Subject: keys generated on one architecture for another? In-Reply-To: <44E465A0.4050805@seiner.com> References: <20060817025936.GZ30226@ucc.gu.uwa.edu.au> <44E465A0.4050805@seiner.com> Message-ID: <200608171352.51596.rob@landley.net> On Thursday 17 August 2006 8:48 am, Yan Seiner wrote: > There are two possibilites I can think of. One is a bug in busybox's > nfs.... The target box (an arm board) is mounting the fs via nfs. It's the kernel's NFS. All BusyBox does is set it up at mount time, after that the kernel's NFS driver takes over. Actually doing stuff with it (like checking file permissions) doesn't involve busybox at all. > > I guess this is a Linux variant from the ps listing. Which > > filesystem is it running? I suspect that's where the problem > > lies. > > > > I suspect there may be some issues between busybox 1.2.1 and my kernel > as pertains to console handling.... I don't know if that's what I'm > seeing here. Not enough info. Rob -- Never bet against the cheap plastic solution. From matt at ucc.asn.au Sat Aug 19 23:05:07 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 19 Aug 2006 23:05:07 +0800 Subject: 'received data with bad writefd' In-Reply-To: <3534fd3a0608170410w4f2c0d3amcbf1f79f919b8bed@mail.gmail.com> References: <3534fd3a0608170410w4f2c0d3amcbf1f79f919b8bed@mail.gmail.com> Message-ID: <20060819150507.GC30226@ucc.gu.uwa.edu.au> On Thu, Aug 17, 2006 at 04:10:59AM -0700, Haseeb Abdul Qadir wrote: > Hi, > > When using dropbear for port forwarding only (no command shell, no pty) the > sever sometimes unexpectedly exits with: > > [21929] Aug 17 06:29:01 exit after auth (haseebq): received data with bad > writefd > > Its not a 100% repro but I have seen it happen a few times. Any idea how I'd > diagnose this? I suspect that this is a bug in the channel-close code. I think what's probably happening is that queued packets from the remote end keep getting processed after the forwarding socket has been closed. I'll try and track down exactly what's going on - as a workaround replacing the "received data with bad writefd" line in common-channel.c with just 'return;' should work. Cheers, Matt From rich at storix.com Wed Aug 23 04:27:52 2006 From: rich at storix.com (Rich Turner) Date: Tue, 22 Aug 2006 13:27:52 -0700 Subject: dropbear and libnss Message-ID: <200608221327.53440.rich@storix.com> i am using dropbear as part of a bootable cd. everything works fine when i include the libnss_files files but i am unable to authenticate without them. if i need libnss_files then why is not dropbear library dependent on libnss_files? if i run ldd on all of the executables i include on the bootable cd, none are dependent on libnns_*. is there something i do not understand about libnss and linux authentication or is dropbear trying to load a subroutine in libnss that does not exist? From andyw at pobox.com Wed Aug 23 04:46:14 2006 From: andyw at pobox.com (Andy Warner) Date: Tue, 22 Aug 2006 15:46:14 -0500 Subject: dropbear and libnss In-Reply-To: <200608221327.53440.rich@storix.com> References: <200608221327.53440.rich@storix.com> Message-ID: <19106af40608221346t7482c69wa5421e7d4a4454bb@mail.gmail.com> On 8/22/06, Rich Turner wrote: > i am using dropbear as part of a bootable cd. everything works fine when i > include the libnss_files files but i am unable to authenticate without them. > if i need libnss_files then why is not dropbear library dependent on > libnss_files? > > if i run ldd on all of the executables i include on the bootable cd, none are > dependent on libnns_*. > > is there something i do not understand about libnss and linux authentication > or is dropbear trying to load a subroutine in libnss that does not exist? My recollection is that libnss contains the functions that decide how things like gethostbyname() get satisfied. E.g. DNS, /etc/hosts, yp etc etc.) It is included by some obscure path that I can't quite remember, but you're right - it doesn't show up with ldd. Just add it to the list of libraries copied over and you should be good to go. The stock libnss contains runtime switches to control where you get information from, I think there are versions available that allow you to hardcode the source at compile time, if that kind of additional security is important to you. -- Andy From floydpink at gmail.com Wed Aug 23 04:50:07 2006 From: floydpink at gmail.com (Jason Schoon) Date: Tue, 22 Aug 2006 15:50:07 -0500 Subject: dropbear and libnss In-Reply-To: <200608221327.53440.rich@storix.com> References: <200608221327.53440.rich@storix.com> Message-ID: <78a54e1b0608221350g79206fb8wc7ab0be0d2fae5d@mail.gmail.com> On 8/22/06, Rich Turner wrote: > > i am using dropbear as part of a bootable cd. everything works fine when i > include the libnss_files files but i am unable to authenticate without > them. > if i need libnss_files then why is not dropbear library dependent on > libnss_files? > > if i run ldd on all of the executables i include on the bootable cd, none > are > dependent on libnns_*. > > is there something i do not understand about libnss and linux > authentication > or is dropbear trying to load a subroutine in libnss that does not exist? Glibc utilizes libnss for name lookups. Dropbear is not directly dependant on libnss, you have built it dependant on glibc, which is dependant on libnss (unfortunately, even if you statically link). If you build dropbear against uclibc, you will not have this problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060822/ddbc0320/attachment.html From rich at storix.com Wed Aug 23 05:17:08 2006 From: rich at storix.com (Rich Turner) Date: Tue, 22 Aug 2006 14:17:08 -0700 Subject: dropbear and libnss In-Reply-To: <78a54e1b0608221350g79206fb8wc7ab0be0d2fae5d@mail.gmail.com> References: <200608221327.53440.rich@storix.com> <78a54e1b0608221350g79206fb8wc7ab0be0d2fae5d@mail.gmail.com> Message-ID: <200608221417.09206.rich@storix.com> unfortunately using uclibc is not an option for me on this project. is there anyway for dropbear to authenticate without using libnss? my guess is probably not because i have dropbear built against glibc, which needs libnss even though it is not dependent on libnss. On Tuesday 22 August 2006 13:50, Jason Schoon wrote: > On 8/22/06, Rich Turner wrote: > > i am using dropbear as part of a bootable cd. everything works fine when > > i include the libnss_files files but i am unable to authenticate without > > them. > > if i need libnss_files then why is not dropbear library dependent on > > libnss_files? > > > > if i run ldd on all of the executables i include on the bootable cd, none > > are > > dependent on libnns_*. > > > > is there something i do not understand about libnss and linux > > authentication > > or is dropbear trying to load a subroutine in libnss that does not exist? > > Glibc utilizes libnss for name lookups. Dropbear is not directly dependant > on libnss, you have built it dependant on glibc, which is dependant on > libnss (unfortunately, even if you statically link). > > If you build dropbear against uclibc, you will not have this problem. From rob at landley.net Wed Aug 23 07:55:01 2006 From: rob at landley.net (Rob Landley) Date: Tue, 22 Aug 2006 19:55:01 -0400 Subject: dropbear and libnss In-Reply-To: <200608221417.09206.rich@storix.com> References: <200608221327.53440.rich@storix.com> <78a54e1b0608221350g79206fb8wc7ab0be0d2fae5d@mail.gmail.com> <200608221417.09206.rich@storix.com> Message-ID: <200608221955.02011.rob@landley.net> On Tuesday 22 August 2006 5:17 pm, Rich Turner wrote: > unfortunately using uclibc is not an option for me on this project. Not even statically linked? Sad. > is there anyway for dropbear to authenticate without using libnss? my guess > is probably not because i have dropbear built against glibc, which needs > libnss even though it is not dependent on libnss. Alas, there's not much dropbear can do to work around deficiencies in glibc. Rob -- Never bet against the cheap plastic solution. From hcegtvedt at atmel.com Fri Aug 11 14:18:51 2006 From: hcegtvedt at atmel.com (Hans-Christian Egtvedt) Date: Fri, 11 Aug 2006 08:18:51 +0200 Subject: Hash mismatch when SSHing to dropbear server In-Reply-To: <20060809165708.GX6519@ucc.gu.uwa.edu.au> References: <44D205C4.8060000@atmel.com> <20060804054028.GT15998@ucc.gu.uwa.edu.au> <44D300A4.3070205@atmel.com> <20060806160726.GL6519@ucc.gu.uwa.edu.au> <44D85263.8070107@atmel.com> <20060809165708.GX6519@ucc.gu.uwa.edu.au> Message-ID: <44DC214B.3010505@atmel.com> Matt Johnston wrote: > On Tue, Aug 08, 2006 at 10:59:15AM +0200, Hans-Christian Egtvedt wrote: >> I put the logs here: >> http://www.egtvedt.no/dropbear/ >> >>> Hopefully that might be of use. >> I'm not quite seeing what I should be looking for, if anybody have a >> pointer to what I should see (correct calculations etc) then I can start >> my debugging :) > > I've taken another look, turns out that my rigged random > number generator had endian-specific output :( Could you > give it another go with the new version at > http://matt.ucc.asn.au/dropbear/testing/db-unrandom2.tar.gz > , sorry about that. Thanks again for making this test :) > I've put what I see as dump2.gz, it should be the same as > you see on the workstation (at least for the calculations). > > For debugging, I'd compare the two traces (avr versus x86) > using vimdiff or something similar. Find the first point > where they begin to differ in their numeric output (the > big-numbers printed etc), and then add more debugging > statements before and after that to narrow down the point > where they start to differ. (Note that some of the > hexadecimal output will differ with endianness, those should > be marked). I looked in your dump2-ppc vs. dump2, and found that in my x86 vs avr32 I have something faulty with the lines below: X86 mp_int mp_exptmod_fast X: 57177274837176085710416002504255433114092271661685833986820045309615224297446777341551735779854568082929739086299104916069027366371956577873538725199184070295968371188748133537718214011550432576681564852689543774176794595038388421094953024485861852872341010938808415634567578860387138830446329229275810102561 AVR32 mp_int mp_exptmod_fast X: 26144629297143774191971619660891134373249478019090098695819374263386738314451768455401121680453697629379694697503955208976597983567979834942305834318644583895981375065787344042040457278746854017585464708420108154208341890971865764261601653839167444443692604372044120220262714803272834772806762057598126328370 > Have a look at libtommath/bn_mp_exptmod_fast.c for how I've > added the debugging output there - it requires the extra > #include up the top, and order of includes does matter. I'll have a look inside here to see what I find :) > I'd be interested to see the logs, let me know how you go. http://www.egtvedt.no/dropbear/ v2 is the new logs. -- With kind regards, Med vennlig hilsen, Hans-Christian Egtvedt Applications Engineer - AVR Applications Lab Atmel Norway From matt at ucc.asn.au Mon Sep 11 15:55:27 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Mon, 11 Sep 2006 15:55:27 +0800 Subject: [Dropbear] Question about username/password authentication In-Reply-To: <001701c6d54a$f053d580$9f01a8c0@A2391> References: <001701c6d54a$f053d580$9f01a8c0@A2391> Message-ID: <20060911075527.GE26251@ucc.gu.uwa.edu.au> On Mon, Sep 11, 2006 at 10:35:23AM +0800, Vincent wrote: > Drar Matt: > I'm porting Dropbear 0.48.1 into my embedded linux system. > My authentication policy is to replase default /etc/password with my own > username/password library. > > But in svr-authpasswd.c, function void svr_auth_password(), > I don't know where can I found the clear text input password for my check. > > Can you advise me ? Or tell me which function in which file is the correct > way to integrate my own library. Look at http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/2006q3/000416.html for what I've suggested previously. In svr-auth.c the call to getpwnam() returns the struct passwd for the user. Various other parts of Dropbear rely on this being populated with pw_uid, pw_shell, pw_dir etc, so you'll have to fill that out manually even if you're not using /etc/passwd. svr_auth_password() then gets the cleartext password from the authentication packet with "password = buf_getstring(" then crypt()s it and compares it with the stored ses.authstate.pw->pw_passwd. To implement your own policy, replace the getpwnam() call in checkusername() with something of your own, that just checks that the username is valid and fills out the pw_ values. You could probably hardcode the values there if all users log in with the same userid/shell. Then you'll want to replace svr_auth_password() with something that uses the password = buf_getstring(...) and checks the user/password combination with your own code. Let me know if you have any problems. Cheers, Matt From alex.ranskis at gmail.com Tue Sep 12 01:31:30 2006 From: alex.ranskis at gmail.com (Alex Still) Date: Mon, 11 Sep 2006 19:31:30 +0200 Subject: Remote port forwarding (binding to *) Message-ID: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> Hi all, I'm trying to use remote port forwarding, and have had no success making dropbear listen on all interfaces on the remote host. I've looked at the archives, and found the recommendation to use the -a switch, but that doesn't seem to do the trick for me. ive tried these syntax on the client side (openssh) ssh -R 2000::3000 superuser at box ssh -R 2000:*:3000 ... ssh -R 2000::3000 ssh -R 2000:localhost:3000 .. But dropbear binds only to localhost. This is with version 0.48. I start dropbear as 'dropbear -a' Any pointer welcome ! Cheers, -- Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060911/e126c8e4/attachment.htm From matt at ucc.asn.au Tue Sep 12 12:36:23 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 12 Sep 2006 12:36:23 +0800 Subject: Remote port forwarding (binding to *) In-Reply-To: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> References: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> Message-ID: <20060912043623.GV26251@ucc.gu.uwa.edu.au> On Mon, Sep 11, 2006 at 07:31:30PM +0200, Alex Still wrote: > I'm trying to use remote port forwarding, and have had no success making > dropbear listen on all interfaces on the remote host. I've looked at the > archives, and found the recommendation to use the -a switch, but that > doesn't seem to do the trick for me. > > ive tried these syntax on the client side (openssh) > ssh -R 2000::3000 superuser at box > ssh -R 2000:*:3000 ... > ssh -R 2000::3000 > ssh -R 2000:localhost:3000 .. The syntax is "ssh -R port:host:hostport user at hostname" which will forward "port" listening on "hostname" to "host:hostport" via your local ssh-running machine (so 'localhost' means the machine you're currently running on, and the first two make no sense). What are you trying to forward to/from? Running with -a should make the Dropbear server listen on any interface. If you run netstat -antp|grep LISTEN (or similar for your OS) what port does it show it listening on? Matt From alex.ranskis at gmail.com Wed Sep 13 04:02:38 2006 From: alex.ranskis at gmail.com (Alex Still) Date: Tue, 12 Sep 2006 22:02:38 +0200 Subject: Remote port forwarding (binding to *) In-Reply-To: <20060912043623.GV26251@ucc.gu.uwa.edu.au> References: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> <20060912043623.GV26251@ucc.gu.uwa.edu.au> Message-ID: <5187ff020609121302g35915171o81a5c19e98e62e69@mail.gmail.com> On 9/12/06, Matt Johnston wrote: > > On Mon, Sep 11, 2006 at 07:31:30PM +0200, Alex Still wrote: > > I'm trying to use remote port forwarding, and have had no success making > > dropbear listen on all interfaces on the remote host. I've looked at the > > > archives, and found the recommendation to use the -a switch, but that > > doesn't seem to do the trick for me. > > > > ive tried these syntax on the client side (openssh) > > ssh -R 2000::3000 superuser at box > > ssh -R 2000:*:3000 ... > > ssh -R 2000::3000 > > ssh -R 2000:localhost:3000 .. > > The syntax is "ssh -R port:host:hostport user at hostname" > which will forward "port" listening on "hostname" to > "host:hostport" via your local ssh-running machine (so > 'localhost' means the machine you're currently running on, > and the first two make no sense). What are you trying to > forward to/from? I'm trying to do this : baculaserver-----router1----------router2-----laptop Baculaserver and laptop are NAT'ed on their respective network. What im trying to do is SSH from laptop to router1 (running dropbear) and remote forward a port from there back to the laptop running the bacula client. That's why I need the remote forwarding to work on all interfaces on router1. >From laptop : ssh -R 3000:localhost:2000 alex at router1 On router I see : netstat : tcp 0 0 localhost:3000 *:* LISTEN I hope this is more clear and that i haven't missed anything obvious ! Cheers , -- Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060912/65e0c110/attachment.htm From matt at ucc.asn.au Wed Sep 13 11:33:17 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Wed, 13 Sep 2006 11:33:17 +0800 Subject: Remote port forwarding (binding to *) In-Reply-To: <5187ff020609121302g35915171o81a5c19e98e62e69@mail.gmail.com> References: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> <20060912043623.GV26251@ucc.gu.uwa.edu.au> <5187ff020609121302g35915171o81a5c19e98e62e69@mail.gmail.com> Message-ID: <20060913033316.GC26251@ucc.gu.uwa.edu.au> On Tue, Sep 12, 2006 at 10:02:38PM +0200, Alex Still wrote: > I'm trying to do this : > > baculaserver-----router1----------router2-----laptop > > Baculaserver and laptop are NAT'ed on their respective network. What im > trying to do is SSH from laptop to router1 (running dropbear) and remote > forward a port from there back to the laptop running the bacula client. > That's why I need the remote forwarding to work on all interfaces on > router1. > > >From laptop : ssh -R 3000:localhost:2000 alex at router1 > On router I see : > netstat : > tcp 0 0 localhost:3000 *:* LISTEN > > I hope this is more clear and that i haven't missed anything obvious ! Thanks, that's clear :) I've just noticed that OpenSSH ~4.0 added an extra feature to -R, and it now binds to localhost by default (rather than 0.0.0.0 and letting the remote side restrict it further). -R [bind_address:]port:host:hostport So I think you'll want to use "ssh -R :3000:localhost:2000 alex at router1" (an empty bind_address or '*' means any interface). You'll still need -a for Dropbear (equivalent to GatewayPorts mentioned in the ssh manpage). Matt From wimpunk at gmail.com Wed Sep 13 14:33:05 2006 From: wimpunk at gmail.com (Wim Vinckier) Date: Wed, 13 Sep 2006 08:33:05 +0200 Subject: Remote port forwarding (binding to *) In-Reply-To: <20060913033316.GC26251@ucc.gu.uwa.edu.au> References: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> <20060912043623.GV26251@ucc.gu.uwa.edu.au> <5187ff020609121302g35915171o81a5c19e98e62e69@mail.gmail.com> <20060913033316.GC26251@ucc.gu.uwa.edu.au> Message-ID: <5c43128e0609122333l71c5eba5qba8a1e3d864b658@mail.gmail.com> On 9/13/06, Matt Johnston wrote: > On Tue, Sep 12, 2006 at 10:02:38PM +0200, Alex Still wrote: > > I'm trying to do this : > > > > baculaserver-----router1----------router2-----laptop > > > > Baculaserver and laptop are NAT'ed on their respective network. What im > > trying to do is SSH from laptop to router1 (running dropbear) and remote > > forward a port from there back to the laptop running the bacula client. > > That's why I need the remote forwarding to work on all interfaces on > > router1. > > > > >From laptop : ssh -R 3000:localhost:2000 alex at router1 > > On router I see : > > netstat : > > tcp 0 0 localhost:3000 *:* LISTEN > > > > I hope this is more clear and that i haven't missed anything obvious ! > > Thanks, that's clear :) > > I've just noticed that OpenSSH ~4.0 added an extra feature to > -R, and it now binds to localhost by default (rather than > 0.0.0.0 and letting the remote side restrict it further). > > -R [bind_address:]port:host:hostport > > So I think you'll want to use "ssh -R :3000:localhost:2000 alex at router1" > (an empty bind_address or '*' means any interface). You'll > still need -a for Dropbear (equivalent to GatewayPorts > mentioned in the ssh manpage). > > > Matt > don't you need this from your laptop ssh -L 2000:localhost:3000 alex at router1 so you can connect from your laptop to localhost:2000? wim. From alex.ranskis at gmail.com Thu Sep 14 04:28:45 2006 From: alex.ranskis at gmail.com (Alex Still) Date: Wed, 13 Sep 2006 22:28:45 +0200 Subject: Remote port forwarding (binding to *) In-Reply-To: <20060913033316.GC26251@ucc.gu.uwa.edu.au> References: <5187ff020609111031o41d4d243pc1441da9e216c8c4@mail.gmail.com> <20060912043623.GV26251@ucc.gu.uwa.edu.au> <5187ff020609121302g35915171o81a5c19e98e62e69@mail.gmail.com> <20060913033316.GC26251@ucc.gu.uwa.edu.au> Message-ID: <5187ff020609131328s1b56f29al39981960b4a8f14c@mail.gmail.com> > I've just noticed that OpenSSH ~4.0 added an extra feature to > -R, and it now binds to localhost by default (rather than > 0.0.0.0 and letting the remote side restrict it further). > > -R [bind_address:]port:host:hostport > > So I think you'll want to use "ssh -R :3000:localhost:2000 alex at router1" > (an empty bind_address or '*' means any interface). You'll > still need -a for Dropbear (equivalent to GatewayPorts > mentioned in the ssh manpage). That works ! I had read the manpage... but that was a few years ago, oops :) Thanks very much for your help. (to Wim: local forwarding isn't an option, because bacula currently requires that the backup server connects to the client, not the other way around.) Cheers, -- Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060913/6ea6e799/attachment.htm From jamie at shareable.org Thu Sep 14 23:24:53 2006 From: jamie at shareable.org (Jamie Lokier) Date: Thu, 14 Sep 2006 16:24:53 +0100 Subject: [PATCH] wildcard host keys Message-ID: <20060914152453.GA11629@mail.shareable.org> I'm using dropbear on an embedded device that has to connect to a server at an IP address that isn't known in advance, but is verifiable with a host key. So I added the ability to use "*" in the known_hosts file to match any hostname/IP. This is better than disabling host key checking altogether, as I can still verify it's connecting to an authorized server. Someone else may find the patch useful. -- Jamie This allows the known_hosts file to use wildcard "*" to match any host. This is used to prevent the interactive "y/n" question as long as the host key is in the recognised list - essential for non-interactive setup of tunnels, to IPs that aren't known when the /root directory is created. --- dropbear-0.46/cli-kex.c.orig 2006-08-30 03:49:40.000000000 +0100 +++ dropbear-0.46/cli-kex.c 2006-08-30 03:58:54.000000000 +0100 @@ -202,6 +202,14 @@ break; } + /* Match "*" wildcard hostname. */ + if (line->len >= 2 + && strncmp("* ", buf_getptr(line, 2), 2) == 0) { + buf_incrpos(line, 2); + TRACE(("matched wildcard host")) + goto check_algo; + } + /* The line is too short to be sensible */ /* "30" is 'enough to hold ssh-dss plus the spaces, ie so we don't * buf_getfoo() past the end and die horribly - the base64 parsing @@ -225,6 +233,7 @@ continue; } + check_algo: if ( strncmp(buf_getptr(line, algolen), algoname, algolen) != 0) { TRACE(("algo doesn't match")) continue; From jamie at shareable.org Thu Sep 14 23:33:30 2006 From: jamie at shareable.org (Jamie Lokier) Date: Thu, 14 Sep 2006 16:33:30 +0100 Subject: Another question about tunnelling Message-ID: <20060914153330.GB11629@mail.shareable.org> I'm using dropbear to set up a tunnel, using a command like this: dbclient -T -i $HOME/.ssh/id_rsa.db -R 10000:127.0.0.1:23 user at host This works very well, but I'm finding the command terminates after 2 minutes. If I do something equivalent to this, it still terminates after 2 minutes: dbclient -T -i $HOME/.ssh/id_rsa.db -R 10000:127.0.0.1:23 user at host \ 'while :; do sleep 20; echo keepalive; done' I'm surprised that's not enough. To stop it from terminating, I have to send something: (while:; do sleep 20; echo keepalive; done) | \ dbclient -T -i $HOME/.ssh/id_rsa.db -R 10000:127.0.0.1:23 user at host \ 'while :; do sleep 20; echo keepalive; done' As the sole purpose of the dbclient command in this case is to set up a tunnel, is there an easier way to do this than all the extra input? In other words, is there a way to enable keepalive messages without having to pipe something in, perhaps like OpenSSH's ClientAlive options? Thanks, -- Jamie From francesco.andrisani at acotel.com Mon Sep 18 23:29:42 2006 From: francesco.andrisani at acotel.com (Francesco Andrisani) Date: Mon, 18 Sep 2006 17:29:42 +0200 Subject: dbclient: error while loading shared libraries Message-ID: Hi comunity, i've cross compiled dropbear 0.47 for arm linux. I have all ok, but when i try to launch anyone about dropbear, dropbearkey or dbclient i have this error: # ./dbclient ./dbclient: error while loading shared libraries: cannot open shared object file: cannot load shared object file: No such file or directory On my ARM the librarie are on /lib. I have tried to include these libraries with: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib But it don't work. An idea? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060918/b09eda83/attachment.html From matt at ucc.asn.au Tue Sep 19 17:27:18 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 19 Sep 2006 17:27:18 +0800 Subject: Another question about tunnelling In-Reply-To: <20060914153330.GB11629@mail.shareable.org> References: <20060914153330.GB11629@mail.shareable.org> Message-ID: <20060919092718.GW26251@ucc.gu.uwa.edu.au> On Thu, Sep 14, 2006 at 04:33:30PM +0100, Jamie Lokier wrote: > To stop it from terminating, I have to send something: > > (while:; do sleep 20; echo keepalive; done) | \ > dbclient -T -i $HOME/.ssh/id_rsa.db -R 10000:127.0.0.1:23 user at host \ > 'while :; do sleep 20; echo keepalive; done' > > As the sole purpose of the dbclient command in this case is to set up > a tunnel, is there an easier way to do this than all the extra input? > > In other words, is there a way to enable keepalive messages without > having to pipe something in, perhaps like OpenSSH's ClientAlive > options? There's nothing there currently, though I might add something like that in a future version. Cheers, Matt From matt at ucc.asn.au Tue Sep 19 17:29:47 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 19 Sep 2006 17:29:47 +0800 Subject: dbclient: error while loading shared libraries In-Reply-To: References: Message-ID: <20060919092947.GY26251@ucc.gu.uwa.edu.au> On Mon, Sep 18, 2006 at 05:29:42PM +0200, Francesco Andrisani wrote: > > Hi comunity, > i've cross compiled dropbear 0.47 for arm linux. > I have all ok, but when i try to launch anyone about dropbear, dropbearkey or dbclient i have this error: > > # ./dbclient > ./dbclient: error while loading shared libraries: cannot open shared object file: cannot load shared object file: No such file or directory > > On my ARM the librarie are on /lib. > I have tried to include these libraries with: > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/lib > > But it don't work. Do you have ldd on the platform? Try "ldd ./dbclient" and see if any libraries are missing. You might also have a cross-development ldd you could use? If strace is available you could maybe try that and see what libraries it is trying to load before exiting. Matt From jamie at shareable.org Wed Sep 20 09:17:35 2006 From: jamie at shareable.org (Jamie Lokier) Date: Wed, 20 Sep 2006 02:17:35 +0100 Subject: Another question about tunnelling In-Reply-To: <20060919092718.GW26251@ucc.gu.uwa.edu.au> References: <20060914153330.GB11629@mail.shareable.org> <20060919092718.GW26251@ucc.gu.uwa.edu.au> Message-ID: <20060920011735.GC24266@mail.shareable.org> Matt Johnston wrote: > > To stop it from terminating, I have to send something: > > > > (while:; do sleep 20; echo keepalive; done) | \ > > dbclient -T -i $HOME/.ssh/id_rsa.db -R 10000:127.0.0.1:23 user at host \ > > 'while :; do sleep 20; echo keepalive; done' > > > > As the sole purpose of the dbclient command in this case is to set up > > a tunnel, is there an easier way to do this than all the extra input? > > > > In other words, is there a way to enable keepalive messages without > > having to pipe something in, perhaps like OpenSSH's ClientAlive > > options? > > There's nothing there currently, though I might add > something like that in a future version. Thanks for the reply! For reference, I noticed something interesting in the behaviour of keepalives recently. I had a number of little devices running dbclient, connecting to a server running OpenSSH, doing this: dbclient -T -i $HOME/.ssh/id_rsa.db -R 10000:127.0.0.1:23 user at host \ 'while :; do sleep 20; echo keepalive; done' (Note: No input to dbclient, just responses from the server). Those terminate after 2 minutes if there's no traffic over the tunnel. (Conveniently, when there's tunnel traffic, they don't terminate). However, they were connecting over an IP NAT. At some time, it appears the NAT state was reset, so packets from the server could no longer get to the clients. I found (to my surprise) that the clients didn't terminate after this happened. They kept running, with no traffic. This indicates that the 2 minute timeout is not internal to dbclient, but is caused by the OpenSSH server terminating the connection after lack of incoming traffic. But I couldn't find anything in the OpenSSH server config to configure that 2 minutes. Curious. -- Jamie From ndprasad at gmail.com Tue Sep 26 03:26:10 2006 From: ndprasad at gmail.com (Prasad) Date: Mon, 25 Sep 2006 12:26:10 -0700 Subject: offline keygeneration Message-ID: <3351bfbe0609251226v6330b254i39adaa539143cab7@mail.gmail.com> Hi matt, I was checking thro the code to figure out how to make it run faster (I am using dss hostkey now). I found that gen_kexdh_vals (&dh_f, &dh_y) takes about half of the time. So i wrote a task to pre-generate that when the system is not doing anything else and write it in a tmp file. This improves the speed by twice (since dropbear reads the keys from the file when the connection request comes). Now i have few questions, assuming i am going to use dropbear sparsely just to set few parameters. 1) Is this method right? 2) How far is this secure? Assuming i regenerate the key after say 5 minutes of the current login for the purpose of next login. (Till that time if any other login request comes, it can use the same key). 3) The task i wrote does the following initialization, seedrandom(); reseedrandom (); crypto_init() m_mp_init_multi(&dh_priv, &dh_pub, NULL); before calling gen_kexdh_vals (&dh_f, &dh_y). Should i need to add any more of initilisation for offline keygeneration. 4) It also fails few times with this method (need to investigate why) Appreciate your response, Thanx - Prasad On 7/19/06, Matt Johnston wrote: > On Tue, Jul 18, 2006 at 06:53:18PM -0700, Prasad wrote: > > The only problem now i have is that the entire process is really slow > > until i get the login. I takes about 90 secs for me to get the shell. > > (With or with-out the changes for my own interpreter). After i get > > login everything is pretty fast. The size of the SSH key is 1024 bit. > > (512 bytes reduces the time by about 60 secs). > > > > Doing a quick check, majoriy of the time taken was in mp_exptmod() > > routine with each call takes around 25 secs. I am running my > > processor(microblaze) at about 60mhz with hardware multipler, divider > > enabled. > > > > >From your knowledge, Is there any way to accelerate this in software > > or the only way to increase this is by hardware-acceleration? > > Using a DSS hostkey might be faster than RSA, you could try > that. I assume you're already compling with -O2 (or whatever > works for your platform) - that can make a big difference. > Aside from that, I'm not really sure. Looking at a faster > math library (or optimising LibTomCrypt) could be an option. > It looks as if TomsFastMath might be a fairly easy > replacement, though I'm not sure how portable or mature that > is. > > Cheers, > Matt > > From matt at ucc.asn.au Tue Sep 26 20:48:32 2006 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 26 Sep 2006 20:48:32 +0800 Subject: offline keygeneration In-Reply-To: <3351bfbe0609251226v6330b254i39adaa539143cab7@mail.gmail.com> References: <3351bfbe0609251226v6330b254i39adaa539143cab7@mail.gmail.com> Message-ID: <20060926124831.GP28708@ucc.gu.uwa.edu.au> On Mon, Sep 25, 2006 at 12:26:10PM -0700, Prasad wrote: > Hi matt, > I was checking thro the code to figure out how to make it run faster > (I am using dss hostkey now). I found that gen_kexdh_vals (&dh_f, > &dh_y) takes about half of the time. So i wrote a task to pre-generate > that when the system is not doing anything else and write it in a tmp > file. This improves the speed by twice (since dropbear reads the keys > from the file when the connection request comes). > > Now i have few questions, assuming i am going to use dropbear sparsely > just to set few parameters. > 1) Is this method right? > 2) How far is this secure? Assuming i regenerate the key after say 5 > minutes of the current login for the purpose of next login. (Till that > time if any other login request comes, it can use the same key). As far as I can tell, the concept of pregenerating keys should be fine but re-using the same dh_priv value for multiple sessions is a security problem. I'm not a cryptographer so can't give a specific attack, but it seems likely that it would introduce weaknesses to the key exchange procedure. Could you generate several keys with the task while it is running in the background, then use them once only per connection? In a general purpose system it would probably be best to avoid writing keys to disk, but in an embedded system it probably mighn't matter so much (it's a ramdisk anyway?). It'll depend on your application. I'll have a think about a way that Dropbear could do this by default - if the listening process could generate keys while waiting for new connections, but break out upon a client connecting, that would be quite handy. > 3) The task i wrote does the following initialization, > seedrandom(); > reseedrandom (); > crypto_init() > m_mp_init_multi(&dh_priv, &dh_pub, NULL); > before calling gen_kexdh_vals (&dh_f, &dh_y). Should i need to add any > more of initilisation for offline keygeneration. You don't need to call reseedrandom() or crypto_init(), that should be fine I think. > 4) It also fails few times with this method (need to investigate why) No idea there. Thinking a bit more about your hardware, is there any chance of increasing the cache size? (does it have any?) Someone else using libtommath on a microblaze device seems to think that it's the memory speed that makes it so slow [1]. Cheers, Matt [1] http://groups.google.com/group/comp.programming/browse_thread/thread/de98359e049a4297/f17eb1ba71a0bf4e?tvc=2#f17eb1ba71a0bf4e > Appreciate your response, > Thanx > - Prasad > > On 7/19/06, Matt Johnston wrote: > >On Tue, Jul 18, 2006 at 06:53:18PM -0700, Prasad wrote: > >> The only problem now i have is that the entire process is really slow > >> until i get the login. I takes about 90 secs for me to get the shell. > >> (With or with-out the changes for my own interpreter). After i get > >> login everything is pretty fast. The size of the SSH key is 1024 bit. > >> (512 bytes reduces the time by about 60 secs). > >> > >> Doing a quick check, majoriy of the time taken was in mp_exptmod() > >> routine with each call takes around 25 secs. I am running my > >> processor(microblaze) at about 60mhz with hardware multipler, divider > >> enabled. > >> > >> >From your knowledge, Is there any way to accelerate this in software > >> or the only way to increase this is by hardware-acceleration? > > > >Using a DSS hostkey might be faster than RSA, you could try > >that. I assume you're already compling with -O2 (or whatever > >works for your platform) - that can make a big difference. > >Aside from that, I'm not really sure. Looking at a faster > >math library (or optimising LibTomCrypt) could be an option. > >It looks as if TomsFastMath might be a fairly easy > >replacement, though I'm not sure how portable or mature that > >is. > > > >Cheers, > >Matt > > > > From rob at landley.net Wed Sep 27 13:00:26 2006 From: rob at landley.net (Rob Landley) Date: Wed, 27 Sep 2006 01:00:26 -0400 Subject: offline keygeneration In-Reply-To: <20060926124831.GP28708@ucc.gu.uwa.edu.au> References: <3351bfbe0609251226v6330b254i39adaa539143cab7@mail.gmail.com> <20060926124831.GP28708@ucc.gu.uwa.edu.au> Message-ID: <200609270100.26498.rob@landley.net> On Tuesday 26 September 2006 8:48 am, Matt Johnston wrote: > I'll have a think about a way that Dropbear could do this by > default - if the listening process could generate keys while > waiting for new connections, but break out upon a client > connecting, that would be quite handy. If you have to generate a key before you can handle a connection anyway, then in theory you can just generate the key before blocking in accept(), then hand that key off to the new connection and calculate a new one before getting back to accept() in the loop. The upside is you're using time _before_ a connection comes in to generate the key, so if there's any downtime at all between connections you have lower latency answering each new connection, and if they come one after the other you're not noticeably worse. (You can set a backlog with listen, and if you have to finish calculating the key before you can let them try to log on anyway, what's wrong with waiting for the key to finish calculating before handling the connection at all?) The potential downside of this is that somebody connecting and dropping connections to attack the server (with no actual negotiation) can make you eat CPU, but that's not hard to do anyway. Not having looked at how that part of the code's implemented, I could be totally off about this, of course. :) Rob -- Never bet against the cheap plastic solution. From ndprasad at gmail.com Thu Sep 28 09:57:50 2006 From: ndprasad at gmail.com (Prasad) Date: Wed, 27 Sep 2006 18:57:50 -0700 Subject: offline keygeneration In-Reply-To: <20060926124831.GP28708@ucc.gu.uwa.edu.au> References: <3351bfbe0609251226v6330b254i39adaa539143cab7@mail.gmail.com> <20060926124831.GP28708@ucc.gu.uwa.edu.au> Message-ID: <3351bfbe0609271857v6a7c38dfw1dddbc18398d7b3c@mail.gmail.com> > > In a general purpose system it would probably be best to > avoid writing keys to disk, but in an embedded system it > probably mighn't matter so much (it's a ramdisk anyway?). > It'll depend on your application. I am writing it in the /var/tmp which is ramdisk, so it is not a problem. > > I'll have a think about a way that Dropbear could do this by > default - if the listening process could generate keys while > waiting for new connections, but break out upon a client > connecting, that would be quite handy. I am not sure how this might scale for inetd based system. In that case, we need to have a seperate task as i said to achieve this. > > You don't need to call reseedrandom() or crypto_init(), that > should be fine I think. > > > 4) It also fails few times with this method (need to investigate why) > > No idea there. Still i am unsuccessful to make the offline keycreate task stable along with multiple session. When i just initialize bywith seedrandom() and then calling gen_kexdh_vals() in a loop once in a while . The foreground ssh gets struck in the expmod function sometimes or the task sometimes gets memalloc error when couple of ssh request comes simultaenously. I find that libtommath uses too many malloc and free each time. > > Thinking a bit more about your hardware, is there any chance > of increasing the cache size? (does it have any?) Someone > else using libtommath on a microblaze device seems to think > that it's the memory speed that makes it so slow [1]. I already increased the data and instruction cache to max. So i dont think i can increase that anymore. Thanx - Prasad From ndprasad at gmail.com Sat Sep 30 08:02:48 2006 From: ndprasad at gmail.com (Prasad) Date: Fri, 29 Sep 2006 17:02:48 -0700 Subject: offline keygeneration In-Reply-To: <3351bfbe0609271857v6a7c38dfw1dddbc18398d7b3c@mail.gmail.com> References: <3351bfbe0609251226v6330b254i39adaa539143cab7@mail.gmail.com> <20060926124831.GP28708@ucc.gu.uwa.edu.au> <3351bfbe0609271857v6a7c38dfw1dddbc18398d7b3c@mail.gmail.com> Message-ID: <3351bfbe0609291702i184989f9s33e2a34e49b00a68@mail.gmail.com> > > > 4) It also fails few times with this method (need to investigate why) > > > > No idea there. > > Still i am unsuccessful to make the offline keycreate task stable > along with multiple session. When i just initialize bywith > seedrandom() and then calling gen_kexdh_vals() in a loop once in a > while . The foreground ssh gets struck in the expmod function > sometimes or the task sometimes gets memalloc error when couple of ssh > request comes simultaenously. I find that libtommath uses too many Turns out underlying libtommath exp function changes/reallocates the value of alloc and dp (in the mp_int) from whatever allocated in mp_init(). This was the problem that was causing me weird behaviour (becos of uclinux). Now offline keygeneration works fine for me. Thanx for your support matt. - prasad From vapier at gentoo.org Sat Sep 30 08:33:34 2006 From: vapier at gentoo.org (Mike Frysinger) Date: Fri, 29 Sep 2006 20:33:34 -0400 Subject: dropbear build system fixups Message-ID: <200609292033.35512.vapier@gentoo.org> some minor fixes to get dropbear building out of tree ... Makefile.in: - CFLAGS needs to have -I$(srcdir) for options.h and -I. for config.h - please use $(CC) rather than $(LD) so that the compiler driver can handle LDFLAGS properly libtomcrypt/Makefile.in: - aes_enc.o target should use $< rather than referring to the src file directly ... that way VPATH can expand the proper path -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available Url : http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20060929/cfabe886/attachment.pgp