fwtk.gauntlet.random.seed.txt

`Date: Fri, 16 Apr 1999 15:36:27 -0500  
From: [email protected]  
To: [email protected]  
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 [email protected] or via fax to (630) 839-6958.  
  
`