Hi Anton, It certainly is wrong for it to be calling m_burn on the DROPBEAR_PASSWORD environment variable, I'll fix that. I'm not totally sure what the correct behaviour for "change password" or other similar auth prompts is - perhaps DROPBEAR_PASSWORD should only be used for the first "no-echo" response.
In keyboard interactive mode dbclient just gets given a series of "ask the user this question, with echo off/on" prompts from the server - it doesn't really know if it's being asked for the current password, a new password, or something totally different (like a token ID etc). Cheers, Matt On Sat, Dec 05, 2009 at 08:18:11PM +0300, Antony Pavlenko wrote: > Hello. > There is rather unpleasant dbclient behavior when DROPBEAR_PASSWORD is used. > Everything works great until password expiration is used. > Then password is expired and you try to login wuth dbclient with > DROPBEAR_PASSWORD than dbclient will change password to ffff . And there will > be as much 'f' symbols in new password as DROPBEAR_PASSWORD length. > > It works so because in recv_msg_userauth_info_request you call > getpass_or_cancel and if DROPBEAR_PASSWORD is used it returns a pointer to > the DROPBEAR_PASSWORD environment variable. And then you use m_burn to clear > password value from the memory. > > here is the code : > > unsigned char* p = getpass_or_cancel(prompt); > response = m_strdup(p); > m_burn(p, strlen(p)); > > But if this pass is correct and expired than host will ask dbclient to enter > new one pass. dbclient will take DROPBEAR_PASSWORD again but now there is > another pass, which was written by m_burn. > > I like very much DROPBEAR_PASSWORD feature and that dbclient can change > expired password. Also it is great that nobody can dump password from > environment variable. > > I don't know the best way to fix it and doesn't break this great > feature. I can't say that I really understand dropbear code, but may be move > m_burn for environment variable to the end of recv_msg_userauth_specific_60, > or any other place where authorization is really finished? > > With regards, > -- > Anton Pavlenko >
