Re: Dropbear 2019.77
On Tue 29/6/2021, at 9:47 pm, roy...@gmail.com wrote: > >> That itself wouldn't be a problem if we could just crypt all incoming >> password attempts before checking a username's existence - the problem is >> that the password crypt algorithm can vary per user, so the time will vary >> too. We have to guess which algorithm to use for unknown users. So rather >> than adding some complicated logic I just limited the password length. > > OK I got it. But does the risk become higher if I change > DROPBEAR_MAX_PASSWORD_LEN to higher value. for example, 200? If a successful login for a 200 char password takes longer than ~250ms (svr-auth.c send_msg_userauth_failure()) then it's probably possible to figure if usernames exist on a system. That may or may not be a security problem depending on the situation. The length will depend on the speed and crypt algorithms of the system. Cheers, Matt
Re: Dropbear 2019.77
Hello Matt, Matt Johnston wrote: > > Hi Roy, > > On Tue 29/6/2021, at 7:18 pm, roy...@gmail.com wrote: > > > - Make failure delay more consistent to avoid revealing valid usernames, set > server password > limit of 100 characters. Problem reported by usd responsible disclosure team > > > What is the technical reason of limiting server password length to > such a low value? It is even shorter than Windows PATH_MAX which I > think this doesn't make any sense. > > - Change handling of failed authentication to avoid disclosing valid > usernames, > CVE-2018-15599. > > > The problem with longer passwords is that the time taken to calculate a > password crypt is dependent on the length of the password. Passwords longer > than a certain length will take longer to crypt than the failure delay time - > 100 characters was less than what I tried empirically. > > That itself wouldn't be a problem if we could just crypt all incoming > password attempts before checking a username's existence - the problem is > that the password crypt algorithm can vary per user, so the time will vary > too. We have to guess which algorithm to use for unknown users. So rather > than adding some complicated logic I just limited the password length. OK I got it. But does the risk become higher if I change DROPBEAR_MAX_PASSWORD_LEN to higher value. for example, 200? > > Cheers, > Matt Regards, Roy
Re: Dropbear 2019.77
Hi Roy, On Tue 29/6/2021, at 7:18 pm, roy...@gmail.com wrote: > >> - Make failure delay more consistent to avoid revealing valid usernames, set >> server password >> limit of 100 characters. Problem reported by usd responsible disclosure team > > What is the technical reason of limiting server password length to > such a low value? It is even shorter than Windows PATH_MAX which I > think this doesn't make any sense. > >> - Change handling of failed authentication to avoid disclosing valid >> usernames, >> CVE-2018-15599. The problem with longer passwords is that the time taken to calculate a password crypt is dependent on the length of the password. Passwords longer than a certain length will take longer to crypt than the failure delay time - 100 characters was less than what I tried empirically. That itself wouldn't be a problem if we could just crypt all incoming password attempts before checking a username's existence - the problem is that the password crypt algorithm can vary per user, so the time will vary too. We have to guess which algorithm to use for unknown users. So rather than adding some complicated logic I just limited the password length. Cheers, Matt
Re: Dropbear 2019.77
Hi, Sorry for replying such old message, but: Matt Johnston wrote: > > Hi all, > > At long last Dropbear 2019.77 is released. Most changes are > bug fixes, with a few small features. There are security > fixes to avoid revealing the existence of valid usernames. > > This release also merges the fuzzing branch. In a > normal build this should have no effect on operation. > > There are a few larger changes that are ready to merge > that will have to wait for the next release - I wanted to > get this bugfix out of the way first. > > Download at > https://matt.ucc.asn.au/dropbear/dropbear.html > mirror > https://dropbear.nl/mirror/dropbear.html > > Cheers, > Matt > > 2019.77 - 23 March 2019 > > - Fix server -R option with ECDSA - only advertise one key size which will be > accepted. > Reported by Peter Krefting, 2018.76 regression. > > - Fix server regression in 2018.76 where multiple client -R forwards were all > forwarded > to the first destination. Reported by Iddo Samet. > > - Make failure delay more consistent to avoid revealing valid usernames, set > server password > limit of 100 characters. Problem reported by usd responsible disclosure team What is the technical reason of limiting server password length to such a low value? It is even shorter than Windows PATH_MAX which I think this doesn't make any sense. > - Change handling of failed authentication to avoid disclosing valid > usernames, > CVE-2018-15599. > > - Fix dbclient to reliably return the exit code from the remote server. > Reported by W. Mike Petullo > > - Fix export of 521-bit ECDSA keys, from Christian Hohnstädt > > - Add -o Port=xxx option to work with sshfs, from xcko > > - Merged fuzzing code, see FUZZER-NOTES.md > > - Add a DROPBEAR_SVR_MULTIUSER=0 compile option to run on > single-user Linux kernels (CONFIG_MULTIUSER disabled). From Patrick Stewart > > - Increase allowed username to 100 characters, reported by W. Mike Petullo > > - Update config.sub and config.guess, should now work with RISC-V > > - Cygwin compile fix from karel-m > > - Don't require GNU sed (accidentally in 2018.76), reported by Samuel Hsu > > - Fix for IRIX and writev(), reported by Kazuo Kuroi > > - Other fixes and cleanups from François Perrad, Andre McCurdy, Konstantin > Demin, > Michael Jones, Pawel Rapkiewicz Regards, Roy
Re: Dropbear 2019.77
Beware that dbclient in 2019.77 has a regression, it won't reset TTY modes on exit. That's fixed in https://secure.ucc.asn.au/hg/dropbear/rev/4b01f4826a29 Cheers, Matt On Sat, Mar 23, 2019 at 10:02:49PM +0800, Matt Johnston wrote: > Hi all, > > At long last Dropbear 2019.77 is released. Most changes are > bug fixes, with a few small features. There are security > fixes to avoid revealing the existence of valid usernames. > > This release also merges the fuzzing branch. In a > normal build this should have no effect on operation. > > There are a few larger changes that are ready to merge > that will have to wait for the next release - I wanted to > get this bugfix out of the way first. > > Download at > https://matt.ucc.asn.au/dropbear/dropbear.html > mirror > https://dropbear.nl/mirror/dropbear.html > > Cheers, > Matt > > 2019.77 - 23 March 2019 > > - Fix server -R option with ECDSA - only advertise one key size which will be > accepted. > Reported by Peter Krefting, 2018.76 regression. > > - Fix server regression in 2018.76 where multiple client -R forwards were all > forwarded > to the first destination. Reported by Iddo Samet. > > - Make failure delay more consistent to avoid revealing valid usernames, set > server password > limit of 100 characters. Problem reported by usd responsible disclosure team > > - Change handling of failed authentication to avoid disclosing valid > usernames, > CVE-2018-15599. > > - Fix dbclient to reliably return the exit code from the remote server. > Reported by W. Mike Petullo > > - Fix export of 521-bit ECDSA keys, from Christian Hohnstädt > > - Add -o Port=xxx option to work with sshfs, from xcko > > - Merged fuzzing code, see FUZZER-NOTES.md > > - Add a DROPBEAR_SVR_MULTIUSER=0 compile option to run on > single-user Linux kernels (CONFIG_MULTIUSER disabled). From Patrick Stewart > > - Increase allowed username to 100 characters, reported by W. Mike Petullo > > - Update config.sub and config.guess, should now work with RISC-V > > - Cygwin compile fix from karel-m > > - Don't require GNU sed (accidentally in 2018.76), reported by Samuel Hsu > > - Fix for IRIX and writev(), reported by Kazuo Kuroi > > - Other fixes and cleanups from François Perrad, Andre McCurdy, Konstantin > Demin, > Michael Jones, Pawel Rapkiewicz
Re: Dropbear 2019.77
>>>>> "Matt" == Matt Johnston writes: > Hi all, > At long last Dropbear 2019.77 is released. Most changes are > bug fixes, with a few small features. There are security > fixes to avoid revealing the existence of valid usernames. Thanks. Can you please also add the release to: https://matt.ucc.asn.au/dropbear/releases/SHA256SUM.asc Thanks. -- Bye, Peter Korsgaard
Dropbear 2019.77
Hi all, At long last Dropbear 2019.77 is released. Most changes are bug fixes, with a few small features. There are security fixes to avoid revealing the existence of valid usernames. This release also merges the fuzzing branch. In a normal build this should have no effect on operation. There are a few larger changes that are ready to merge that will have to wait for the next release - I wanted to get this bugfix out of the way first. Download at https://matt.ucc.asn.au/dropbear/dropbear.html mirror https://dropbear.nl/mirror/dropbear.html Cheers, Matt 2019.77 - 23 March 2019 - Fix server -R option with ECDSA - only advertise one key size which will be accepted. Reported by Peter Krefting, 2018.76 regression. - Fix server regression in 2018.76 where multiple client -R forwards were all forwarded to the first destination. Reported by Iddo Samet. - Make failure delay more consistent to avoid revealing valid usernames, set server password limit of 100 characters. Problem reported by usd responsible disclosure team - Change handling of failed authentication to avoid disclosing valid usernames, CVE-2018-15599. - Fix dbclient to reliably return the exit code from the remote server. Reported by W. Mike Petullo - Fix export of 521-bit ECDSA keys, from Christian Hohnstädt - Add -o Port=xxx option to work with sshfs, from xcko - Merged fuzzing code, see FUZZER-NOTES.md - Add a DROPBEAR_SVR_MULTIUSER=0 compile option to run on single-user Linux kernels (CONFIG_MULTIUSER disabled). From Patrick Stewart - Increase allowed username to 100 characters, reported by W. Mike Petullo - Update config.sub and config.guess, should now work with RISC-V - Cygwin compile fix from karel-m - Don't require GNU sed (accidentally in 2018.76), reported by Samuel Hsu - Fix for IRIX and writev(), reported by Kazuo Kuroi - Other fixes and cleanups from François Perrad, Andre McCurdy, Konstantin Demin, Michael Jones, Pawel Rapkiewicz
