http://security.lss.hr/en/index.php?page=details&ID=LSS-2004-10-02 [...] ==[ Vulnerability It is possible to determine which user names are valid, which are special, and which ones do not exist on the remote system. That is acomplished by code execution path timing analysis attack at the ProFTPd login procedure. There is a very small (but significant) difference in time delay of code execution path between valid and non-valid user names. That can be used to remotely determine the difference between existent and non-existent users. The time delay can be measured by using a simple FTP client that will calculate elapsed time between 'USER' command sent by client, and the server response. Because of the very short response period, elapsed time should be measured in microseconds. LSS has developed simple PoC exploit that is presented here: [...] Average login time for non existent user is about 430 usec. The time difference between three types of user accounts is evident, making it easy to determine other valid, non-valid, and special user accounts. This vulnerability can be used to launch more efficient brute-force attacks. ==[ Affected Version Vulnerability was successfully tested on ProFTPD versions 1.2.8 and 1.2.10, but other versions may be vulnerable as well. Test server was placed on the local Ethernet 10/100 network, and tests were conducted over the Internet. ==[ Fix Pseudo-random usleep() at the login procedure that will obfuscate time leak. Something like this: proftpd-1.2.10/modules/mod_auth.c 1867a1868,1877 > { > unsigned int randa; > struct timeval tv; > struct timezone tz; > gettimeofday (&tv, &tz); > srand(tv.tv_usec); > randa = rand() % 20000; > usleep(randa); > } > After this simple patch is applied, it is impossible to tell which users do and don't exist: [...] ==[ PoC Exploit Proof of concept code can be downloaded at http://security.lss.hr/PoC ==[ Credits This vulnerability was found by Leon Juranic (ljuranic@LSS.hr). ___ http://securitytracker.com/alerts/2004/Oct/1011687.html Impact: Disclosure of user information Exploit Included: Yes Version(s): 1.2.8, 1.2.10; possibly other versions Description: A vulnerability was reported in ProFTPd. A remote user can determine valid user account names on the target FTP server. LSS Security Team reported that a remote user can determine valid user account names using a code execution path timing analysis attack against the ProFTPd login procedure. The report indicates that there is a very small, but still significant, difference in the amount of time required to process valid usernames versus invalid usernames. A remote user can measure the elapsed time between the transmission of the 'USER' command and the receipt of the server response. Then, based on the different response times, the remote user can determine which requested user account names are valid. Demonstration exploit code is available at: http://security.lss.hr/PoC Leon Juranic is credited with discovering this flaw. The original advisory is available at: http://security.lss.hr/index.php?page=details&ID=LSS-2004-10-02 Impact: A remote user can determine valid user account names on the target FTP server. Solution: No solution was available at the time of this entry. The author of the report has provided the following unofficial patch: proftpd-1.2.10/modules/mod_auth.c 1867a 1868,1877 > { > unsigned int randa; > struct timeval tv; > struct timezone tz; > gettimeofday (&tv, &tz); > srand(tv.tv_usec); > randa = rand() % 20000; > usleep(randa); > } > ___ http://secunia.com/advisories/12836/ Description: LSS Security Team has reported a weakness in ProFTPD, which potentially can be exploited by malicious people to determine valid usernames. The problem is that there is a time delay difference in the login process for existing and non-existing usernames. This can be exploited to determine valid user accounts and potentially their privileges by sending some "USER" commands and calculating the response period. The weakness has been reported in version 1.2.x. Other versions may also be affected. Solution: Restrict access to the FTP server. Provided and/or discovered by: LSS Security Team
Acording to the Proftpd team this is a security issue present in "any" login system, also the patch does not solve the issue under all circunstances. There is no timetable on when will a patch be available.
hi, please note also, that i consider the gentoo-linux apache2 default configuration insecure... (maybe a new bug? dunno...) you can basically filter valid and invalid usernames much easier with apache.. ... code ... LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so ... code ... i definitely would call this a security flaw... (possible open proxy) ... code ... LoadModule userdir_module modules/mod_userdir.so ... code ... this default configuration, of course, can (and is constantly) abused to test for valid users on a system... no need for timing attacks here... ;-) tell me, what you think about it... best regards florian [rootshell]
Well i must agree with Florian about the: LoadModule userdir_module modules/mod_userdir.so It is really easy to get valid answers (good page, 403 - there is a user, 404 user) But i dont understand the others. But returning to the proftpd bug. We could apply the bug BUT this vuln is still there and hard to fix, from my talks with Castiglia (proftpd maintainer) the same vuln exists in openssh and other software packages. Are we going to keep this open until a good solution exists or close it?
Florian : please file another bug on the vulnerable-by-default apache thing. On the proftpd thing, it's true that info leak by timing attacks do not affect only proftpd. Even openssh when used with PAM is vulnerable to that too. "Are we going to keep this open until a good solution exists or close it?" Good question. I don't like having bugs that we won't fix lying around in my bug list, but it's good to keep an eye on it... So we'll wait for other opinions from security members...
This is a valid security bug -- it should not be possible to glean usernames in this fashion. The ProFTPD guys have acknowledged this and indicate they're working on a solution to the issue. I'd suggest we keep this open given that they are working on it. As for the larger issue of OpenSSH and other apps that have a similar problem...no t sure what the best answer is here. One option would be to issue a one-time blanket GLSA explaining the problem and that there really is no solution at this time. That at least informs our users of the issue. I'm open to other suggestions as well.
From upstream: The ProFTPD Project team has developed a mod_delay module to help mitigate the timing leak described by Leon Juranic. This module will be included in the next release of ProFTPD. Details on the module can be found here. http://www.castaglia.org/proftpd/modules/mod_delay.html
Apparently still nothing new upstream about a release date.
I'm adding version 1.2.10-r1 with a fix for this problem. It will be marked stable on x86 in a day or two.
Thanks Gustavo :) arches, please test proftpd-1.2.10-r1 and mark stable if possible current KEYWORDS="~x86 ~sparc ~hppa ~alpha ~ppc ~mips ~amd64" target KEYWORDS="x86 sparc hppa alpha ppc ~mips amd64"
stable on amd64
Marked stable on ppc.
readding amd54, since it is not marked stable in cvs yet current KEYWORDS="x86 ~sparc ~hppa ~alpha ppc ~mips ~amd64" also sparc, alpha and hppa need to test and mark this stable
sparc stable.
uh oh ;) amd64 stable now (hopefully)
thanks blubb and ummm I meant amd64 of course and not amd54 ;-) since we are nearly done with stable marking... security, please vote on GLSA publication (B4)
Note to security team: The new module was designed to be active by default, the user can if he wants to deactivate it in the config file, so this will CLOSE the bug.
I would say this doesn't need a GLSA.
I would vote no on GLSA-need too.
Stable on alpha.
I'd say no too, closing without GLSA
Stable on hppa.
