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 firewallat_private or via fax to (630) 839-6958.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:42:47 PDT