× Few antiviral products inadequately detect 3proxy as Trojan.Daemonize, Backdoor.Daemonize, etc and many detect 3proxy as a PUA (potentially unwanted program). It may cause browser warning on download page. 3proxy is not trojan or backdoor and contains no functionality except described in documentation. Clear explanation of this fact is given, for example, in Microsoft's article.

Topic                   : Vulnerabilities in multiple RADIUS clients and
Author                  : 3APA3A <[email protected]>
Released                : December, 18 2001
Affected Software       : Lucent/Livingston RADIUS <3= 2.1 (1)(2?)
                          Cistron <3= 1.6.4 (1)(2)
                          Cistron 1.6.5 (2)
                          XtRadius <3= 1.1-pre1 (1)(2)
                          FreeRADIUS <3= 0.3 (1)(2)
                          ICRadius <3= 0.18.1 (1)(2)
                          YARD Radius <3= 1.0.19 (1)(2**)
                          Ascend RADIUS <3= 1.16 (1)
                          Merit RADIUS <3= 3.6B2 (1*)
                          GNU Radius <3= 0.95 (1)
                          radiusclient <3= 0.3.1 (1)
Not affected            : Microsoft IAS (according to vendor)
                          FreeRADIUS 0.4
Risk                    : Medium to High
Remote                  : Yes
Exploitable             : Yes
SECURITY.NNOV advisories: http://www.security.nnov.ru/advisories
FreeRADIUS project      : http://www.freeradius.org
Acknowledgments:        : Thanx to Alan DeKok for FreeRADIUS project
                          Thanx to CERT for help in contacting vendors

* - Vulnerability present but is not exploitable
? - vendor reports not-vulnerable.
** - vulnerability in USR-specific attributes


Remote  Authentication  Dial  In User Service (RADIUS) is widely used by
multiple  ISP  for authentication of users and accounting. RADIUS server
usually  performs  authentication and accounting on requests from RADIUS
client  (also  known  as Network Access Server - NAS). Almost any modern
hardware  or  software  access  server  can act as RADIUS client. During
internal  audit  of  FreeRADIUS  [1] project before 0.4 release few bugs
were  fixed  in  code inherited from older RADIUS implementations. Since
almost  any current implementation of RADIUS servers and multiple RADIUS
clients has code derived from Merit, Ascend or Livingston these bugs may
still  present  in  different  software. Both RADIUS servers and clients
(access servers) are vulnerable.


 (1) Multiple  implementations  of the RADIUS protocol contain a Digest
     Calculation buffer overflow

     To  validate  few  types of RADIUS packets RADIUS calculates packet
     digest. Digest calculated as MD5 hash from packet concatenated with
     message  authenticator  and  shared  secret.  The  problem is, that
     during  concatenation multiple RADIUS implementations fail to check
     target  buffer  has  enough space. It makes it possible to overflow
     buffer  with  shared  secret  data. This bug presents in all RADIUS
     implementations derived from Merit/Ascend.

     RADIUS  client is vulnerable during parsing of Server reply. Server
     is vulnerable during parsing of Accounting packets and during packet
     proxing.  In most cases it will cause DoS against RADIUS server. In
     few  cases under very rare conditions discussed later it may result
     code execution.

     Function, where overflow occurs may have different names:

      response_match(): Merit
      calc_digest()/calc_acctdigest(): Livingston, Cistron and derived
      rc_check_reply(): radclient
      rad_proxy()/calc_acctreq()/build_packet(): yardradius

     Vulnerable piece of code looks like:

      memcpy(buffer+len, secret, secretlen);

 (2) Multiple  implementations of the RADIUS protocol do not adequately
     validate the Vendor-Specific attribute Vendor-Length.

     Vendor-Specific  attribute  is  a  subset  of  sub-attributes. Each
     sub-attribute usually has 2 bytes header (first byte is Vendor-Type
     and  second  byte  is  Vendor-Length), except USRobotics attributes
     where  header  is 4 bytes. Vendor-Length should be greater or equal
     to header length.

     The  problem  is that multiple RADIUS implementations fail to check
     Vendor-Length    than   calculating   amount   of   data   inside
     Vendor-Specific sub-attribute. If Vendor-Length is 0 data size will
     be calculated as negative number.

     Later  memcpy  is  called  with  this  number to copy data. In most
     systems  result  of  this  attack  will  be  DoS against RADIUS (if
     memcpy() implementation is not completely flawed).

     In   most   RADIUS   servers  vulnerable  function is rad_recv() or
     Vulnerable piece of code looks like
        ptr += 4;
        vendorlen = attrlen - 4;
        attribute = *ptr++ | (vendorcode << 16);
        attrlen   = *ptr++;
        attrlen -= 2;
        length -= 6;

     Some  implementation has the same bug in processing of USR-specific
     attributes (and other non-standard Vendor-Specific attributes).

     This bug can be exploited with any type of RADIUS packet.

 To  exploit  this vulnerabilities against RADIUS server attacker should
 be  able to send RADIUS packets from IP of registered NAS. Since RADIUS
 uses  UDP  as transport layer it's easy to spoof NAS' IP address. Since
 both  bugs  occurs  before  packet  is validated no knowledge of shared
 secret required.

 To  exploit  this  vulnerability  against  RADIUS client (NAS) attacker
 should guess client's UDP port. In many cases this port is predictable.

 Attached  test_radius  tool  may  help  you  to reproduce situation (it
 doesn't  spoof IP, so then testing against RADIUS server IP of the host
 you  running  this tool should be registered as valid NAS). test_radius
 may also be obtained from

 For  (1)  buffer overflowed by shared secret which (in general case) is
 not  known  to attacker. Attacker is not able to control this data, but
 he  is able to control length of the data. It makes it possible to make
 1-byte  or  2-bytes  buffer overflow. In this case if last symbol(s) of
 shared  secret  is  in appropriate range it may be possible to use this
 overflow  for  code execution in few implementation. Sometimes it looks
 possible  to  exploit  it  blindly,  for  example this is definition of
 buffer in one of RADIUS implementations:

            static int       i_recv_buffer[RAD_BUFFER_SIZE];
            static u_char    *recv_buffer = (u_char *)i_recv_buffer;

 Receiving function works with recv_buffer.
 Theoretically it's possible to write to any memory location in 3 steps:
  1.  We  do 1-byte overflow to change last byte of recv_buffer to point
  to middle of i_recv_buffer (it will happen only if last byte of shared
  secret is higher then lowest byte of i_recv_buffer address).
  2.  Now  we  can overwrite recv_buffer with data controlled by us with
  second packet.
  3.  Now  data  of  the  third  packet  will  be written to location we
 Of  cause exploitation is only possible if all 3 packets are handled in
 the  same  thread (I didn't checked the code but probably it's true). I
 bet   probability   of   successful  exploitation  is  not  high,  but
 may be positive.

 to reproduce this problem you may use something like

    test_radius RADIUS_SERVER 1 100 MAX_PACKET_SIZE 10 1646 4

 where RADIUS_SERVER is ip of your RADIUS host
 MAX_PACKET is compiled maximum packet size, you can try different:
 1024, 2048, 4096, 8192, etc
 (this command will send radius accounting packet of MAX_PACKET_SIZE)

 (2) can be tested with

  test_radius RADIUS_SERVER 11 20 311 0

 (malformed Microsoft MS-CHAP-Challenge packet)


  test_radius RADIUS_SERVER 1 100 9 0

 (malformed CISCO Cisco-AVPair packet)
 test_radius  may  also  be used as a stress-testing tool against memory
 exhaustion problem described in [2].

  test_radius RADIUS_SERVER 1 2 MAX_PACKET_SIZE 100000


[1] http://www.freeradius.org
[2] http://online.securityfocus.com/archive/1/239784
[3] http://www.security.nnov.ru/files/test_radius.c