Everhart, Glenn (FUSA) From: kadokev@MSG.NET Sent: Friday, April 16, 1999 4:36 PM To: BUGTRAQ@NETSPACE.ORG Subject: FWTK, Gauntlet 'random seed' security problem Summary A 'random seed' problem in lib/rand.c affects all local challenge-response authentication on FWTK and Gauntlet. Many services have support available for this authentication service, including versions of ssh, ftp and telnet. Synopsis The problem discussed in this paper affects all the 'random challenge' authentication methods in Unix platform releases both FWTK and of Gauntlet, though 4.x. The affected challenge-response methods include Cryptocard, SNK (Axent) and md5 authentication, as well as RADIUS CHAP. This problem does not affect the 'Defender' (DSS), or S/Key authentication methods. Simply put, if you know the response to any one challenge (from sniffing the cleartext exchange, shoulder surfing, etc.), you can predict when the authsrv will generate that same challenge again and possibly manipulate it into repeating the challenge within minutes. Description The random number routine in the FWTK library 'seeds' (initializes) the Unix random number generator using only time and process id information, making the sequence of challenges trivially easy to predict. This weakness is similar to the 1995 Netscape 'random seed' security problem, and a real fix is likely to be machine-dependent. Attacks based on the vulnerability are made easier if the authentication server is running any additional services, especially if the attacker can determine the system time and drive up the process ID (cause new processes to be spawned, and 'hold' certain process IDs). An attack is trivially easy from a command prompt on the host running the authentication server. Attacks would be nearly impossible with a real pseudo-random seed and a limit on the duration and number of 'authorize' commands in a single connection to the authentication server. It would also help to treat 'abandoned' challenges the same as authentication failures, eventually locking the account. The authsrv listens on a network port (defaults to 7777) but can be configured to only accept authentication requests from specific IP addresses. Most sites will have the authsrv configured to only accept requests on the loopback address 127.0.0.1, and thus are only vulnerable to local attacks. Predictable challenges, small challenge space Any user with shell access to the authsrv host, and potentially some remote users, can not only predict the sequence of challenges, but with some effort can maneuver the server into generating a certain specific challenge, presumably one to which the response is already known. As well, the way in which the random seed is generated ensures that, of the one-million possible challenges (ten million for Cryptocard), only 32K unique initial challenges will be generated. Being able to predict the challenge is bad, but being able to cause the server to generate a specific challenge (one for which you know the response) is an exploitable security hole. Specific programming errors The first time the randomnumber() function in lib/rand.c is called, authsrv sets the seed with this code: long randomnumber() { static int initt = 0; if(!initt) { long tbuf; time(&tbuf); srand(((int)tbuf % getpid()) + getppid()); initt++; } return(rand()); } Whether run as a daemon or from inetd, each authentication instance is a new process, thus srand() is called to set a new seed when sending the first challenge, then not called again for subsequent challenges in the same process. I've written sample code to demonstrate the problem, the code is available from my web site. This code has been tested on Sparc Solaris 2.6 against both FWTK 2.1 and Gauntlet 4.2. Ramifications Any person with shell access to the authentication server host knows or can predict all the factors, and through careful use of fork() can influence the process ID to bring about a specific sequence of challenges. The easiest exploit uses authsrv management functions, however it is possible to gain access to any service that authenticates through the 'authsrv' service. If the user for which you've sniffed a challenge-response has 'wiz' or 'superwiz' access, you can use the authsrv to add your own entries, with plaintext reusable passwords, or with 'superwiz' to change the password for any user or to add new 'wiz' and 'superwiz' users. Because the authsrv process does not implement a timeout, you can open a connection to the authentication server (locking in the parent and current process id), then wait indefinitely for the epoch clock to increment to a value that will produce a challenge with a known response. This 'known challenge' doesn't have to be the first one presented -- after generating the first challenge, the authsrv has set off down a given 'path' of challenges. This is actually an interesting area of security that I plan to explore in detail in future papers. By determining what 'path' the server is on, if you know that the 50th challenge in the sequence will be the one to which you know the answer, you can send 49 'authorize' requests and only give a 'response' to the 50th question, the one to which you know the answer. This is possible because these 'abandoned' challenges do not count as bad authentications and will not cause authsrv to lock the account. If one can determine the system time remotely and can drive up the process ID through an accessible service (such as smtpd) a remote exploit may be possible. Fix The solution to this problem is the same as the solution to the Netscape bug -- find a better random seed. Replay attacks would also be much more difficult if the authsrv program limited the duration of each connection and the number of 'abandoned' authorization attempts for each user. I have a trivial fix for both FWTK and Gauntlet binaries that uses LD_PRELOAD to replace the system functions rand() and srand(). Vendor Status TIS and Network Associates were first notified on January 12, 1999 when this bug was initially discovered in the free FWTK product. Network Associates was notified on March 4, 1999 when the same problem was confirmed in the most recent release of Gauntlet. They are aware of the problem and have replied that they are developing patches for Gauntlet 5.0, but would not commit to a release date or patches for Gauntlet 4.2 and earlier. Further Information A HTML version, sample code, and further details on this problem are available at http://www.msg.net/utility/FWTK/ _________________________________________________________________ Credits Thanks to Mike Scher for his input, and to TIS for the free source version of the Firewall Toolkit package. I hope that this problem encourages them to improve both the free and commercial versions of what I feel is one of the best Unix firewall packages on the market. Copyright © 1999 by MSG.Net, Inc. Permission is hereby granted for the redistribution of this file in both electronic and print media, in complete and unmodified form only. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no event shall the author be liable for any damages whatsoever arising out of or in connection with the use or distribution of this information. Any use of this information is at the user's own risk. Contact Information All questions may be directed to firewall@msg.net or via fax to (630) 839-6958.