<div>Hello.<br></div><div>First of all thanks a lot for your great ssh client/server!</div><div>As for me, it isn't really "totally wrong" to call m_burn on the DROPBEAR_PASSWORD. It is really useful feature because when ssh session already established nobody can find correct password at /proc/pid/ environ ( Linux ) or pargs -e ( Solaris ).</div>
<div>So it will be great not just remove m_burn for DROPBEAR_PASSWORD but just move to any place, after authorization.</div><div><br></div><div>With regards,</div><div>Anton Pavlenko</div><br><div class="gmail_quote">On Tue, Dec 8, 2009 at 2:34 AM, Matt Johnston <span dir="ltr"><<a href="mailto:matt@ucc.asn.au">matt@ucc.asn.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Anton,<br>
<br>
It certainly is wrong for it to be calling m_burn on the<br>
DROPBEAR_PASSWORD environment variable, I'll fix that. I'm<br>
not totally sure what the correct behaviour for "change<br>
password" or other similar auth prompts is - perhaps<br>
DROPBEAR_PASSWORD should only be used for the first<br>
"no-echo" response.<br>
<br>
In keyboard interactive mode dbclient just gets given a<br>
series of "ask the user this question, with echo off/on"<br>
prompts from the server - it doesn't really know if it's<br>
being asked for the current password, a new password, or<br>
something totally different (like a token ID etc).<br>
<br>
Cheers,<br>
<font color="#888888">Matt<br>
</font><div><div class="h5"><br>
On Sat, Dec 05, 2009 at 08:18:11PM +0300, Antony Pavlenko wrote:<br>
> Hello.<br>
> There is rather unpleasant dbclient behavior when DROPBEAR_PASSWORD is used.<br>
> Everything works great until password expiration is used.<br>
> 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.<br>
><br>
> 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.<br>
><br>
> here is the code :<br>
><br>
> unsigned char* p = getpass_or_cancel(prompt);<br>
> response = m_strdup(p);<br>
> m_burn(p, strlen(p));<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> I don't know the best way to fix it and doesn't break this great<br>
> 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?<br>
><br>
> With regards,<br>
> --<br>
> Anton Pavlenko<br>
><br>
<br>
</div></div></blockquote></div><br>