Although RDIST suggests running 'radiusd' chroot, chroot is not a
panecaea for security holes that yield root. Ideally the program would
bind the radius and radacct ports, chroot, then run setuid as a unique,
unprivileged user (like some HTTPDs), preferably a user that isn't
allowed to rlogin... (see why below).
The quickie patch to fix this buffer overflow in Livingston Radius 1.16
follows:
#---[ cut here ]---
58a59
> static char hostnamebuffer[100];
67c68,69
< return(hp->h_name);
--- > strncpy(hostnamebuffer, hp->h_name, 99); > return(hostnamebuffer); #---[ cut here ]---Save the above lines to a file in your radius 'src' directory named 'fix' then execute 'patch < fix'. When it asks for a filename, enter 'util.c', it should print something about two 'hunks' succeeding. Now build and install normally. You're halfway there...
RDIST mentions a forthcoming patch to do address checking before processing incoming packets- this doesn't prevent the above problem in cases where it's easy to forge UDP packets onto the LAN, but it's a good idea anyway.
In a related note, a vulnerability in the RADIUS protocol itself is noted, basically with a simple sniffer data can be collected such that a 'crack' style dictionary attack on the 'shared secret' (the password stored in the clients file) is possible.
Once the secret is found, forged Access-Accept packets (same as used to exploit the above hole) can be generated, completing the attack and comprising any account that can log in via the terminal server.
The advisory suggests:
> >What this means to you is that you should immediately make sure that all > >your RADIUS "shared secrets" (the password, in /etc/raddb/clients and > >keyed into your terminal servers) are NOT in a dictionary and are at LEAST > >16 characters long. The security of the passphrase is, in many cases, > >roughly equivalent to that of a Unix password entry. If you're not > >absolutely confident in the security of your passphrase, remove any > >mention of your terminal servers from your /etc/hosts.equiv files. ... > >Something to remember: the Livingston documentation will tell you that you > >can rid yourself of those unsightly second password requests from NAS > >rlogin sessions by sticking the IP address of the terminal server in > >/etc/hosts.equiv. The logic behind this is that people coming through the > >terminal server have already authenticated themselves, so your Unix system > >can trust incoming connections from the terminal server. > > > >This is a bad idea. > > > >Beyond RADIUS attacks, bear in mind that anyone with ANY means of > >compromising the terminal server now has an open door into your server > >network. > > > >Because of this, we advise against trusting NAS equipment on Unix > >machines. Create a simple user profile in your RADIUS user file "i.e., > >username 'jisp'" that will automatically present people with a telnet or > >appropriate rlogin prompt for your shell machines.
Send e-mail to Thomas Ptacek as tqbf@rdist.org for further information.