CVE-2000-0321

• BID:1147
• URL:http://www.securityfocus.com/bid/1147
• BUGTRAQ:20000424 Buffer Overflow in version .14
• URL:http://archives.neohapsis.com/archives/bugtraq/2000-04/0190.html

 Frech> XF:icradius-username-bo
   Every reference I pull up shows the product's name as ICRADIUS. See
   http://mysql.eunet.fi/Downloads/Contrib/icradius.README
 Christey> In a followup, Alan DeKok (aland@FREERADIUS.ORG) says that
   this could occur in other RADIUS servers also; however, the
   bug could only be exploited if someone has altered the
   configuration file, which shouldn't normally be modifiable
   by anyone else.
   
   So, this should be REJECTed since the bug doesn't directly give
   anyone else any additional privileges or access.
 Christey> Alan DeKok <aland@FREERADIUS.ORG> says it applies to other RADIUS
   programs also, *however* since it needs a valid username, only
   the RADIUS owner can exploit it by changing the config file.  But
   if the config file can be written by others - well, that's still
   a potential risk, but you've probably got bigger problems then.
   - http://marc.theaimsgroup.com/?l=bugtraq&m=95671883515060&w=2
   Look at ChangeLog at ftp://ftp.cheapnet.net/pub/icradius/ChangeLog
   
   Possible confirmation in 0.15: "sql_getvpdata now dynamically
   allocates buffer sizes for sql queries to avoid over runs"
   
   But that's a bit general.
   
   Alan Kok said that Cistron and other RADIUS servers were affected; the
   ICRADIUS changelog says to check the Cistron logs for other possible
   bug fixes, since ICRADIUS uses Cistron codebase.  Go back to
   freeradius.org and find link to Cistron at
   http://www.miquels.cistron.nl/radius/
   
   Cistron changelog at http://www.miquels.cistron.nl/radius/ChangeLog It
   has different version numbers - go back to ICRADIUS changelog to find
   rought equivalents.  ICRADIUS 0.15 uses Cistron 1.6.3 patches, so
   start from there.
   
   No apparent problems in 1.6.3 or 1.6.4, but 1.6.1 says: "Fix all
   strcpy(), strcat(), sprintf() and sccanf() calls for buffer
   overflows."  So perhaps the problem was fixed then?  Or maybe the
   vulnerable sscanf() call was missed and/or disregarded because it was
   believed that the hostname could be trusted since it came from a
   well-controlled configuration file?