[Bug-gnu-radius] Re[2]: SECURITY.NNOV: vulnerabilities in multiple RADIUS servers and clients. - VU#936683

[3APA3A]

Hello CERT(R),

Please  note, that some of systems derived from Livingston with only (1)
are  not  exploitable  (superfluous  data  rewrites  send buffer without
changing  some  significant  data).  Only  Merit  RADIUS looks not to be
exploitable at all.

Merit - looks not exploitable
YardRADIUS - looks not exploitable with (1)
Livingston - looks not exploitable with (1)
Radiusclient - looks not exploitable by itself, but it's just a library
  and everything will depend on how it's used by software. Software
  doesn't expect digest calculation routine to add something to data
  buffer.
GNU  Radius  is exploitable (pointer located after static buffer will be
 overwritten)
ICRadius - is exploitable in a same way
XTRadius - is exploitable in a same way
Cistron - is exploitable in a same way
Ascend  -  is  exploitable  (ascendd) - EBP/EIP overwritten on stack (it
 cannot  be used for code execution unless attacker can't control shared
 secret)
older  FreeRADIUS  -  is exploitable, impact is not clear - data on heap
 is  overwritten.  If  some  length is overwritten it may lead to buffer
 overflow  in  another place with remote root compromise even if atacker
 doesn't  control  shared  secret...  But it's the only case this bug is
 already patched :)

All  servers/clients  with  (2) are exploitable.

This is a list of e-mail I've sent advisories:

address@hidden - OS Vendors list supported by Olaf Kirch
address@hidden - I love this address
address@hidden - Miquel van Smoorenburg, Cistron
address@hidden   -   Xtradius.   This   address was unreachable, I
 don't know how to contact Xtradius.
address@hidden - Ascend
address@hidden, address@hidden - Merit
address@hidden - Yard
address@hidden  - GNU RADIUS, I've just found that advisory also should
be  sent  to address@hidden - but I didn't yet. I send a copy of
this mail.
address@hidden - radclient
address@hidden, address@hidden - ICRadius

I've got no replies (except one from MS).

I've also notified
address@hidden, address@hidden, address@hidden
But it looks like Livingston RADIUS is not longer supported.

--Friday, January 04, 2002, 1:39:27 AM, you wrote to address@hidden:

CRCC> -----BEGIN PGP SIGNED MESSAGE-----

CRCC> Hello,

CRCC>     Thank you for CC'ing us on these messages, we have assigned these
CRCC> problems to VU#936683. Please include this tag in the subject line of
CRCC> future messages to ensure your mail gets sent to the right place. 

CRCC> Due to the nature of the problems, and the number of systems
CRCC> potentially affected, we would like to ask you to delay the release of
CRCC> your advisory. We would like to further investigate the scope of this
CRCC> problem. From your mail messages we can see that you have contacted
CRCC> Microsoft, Lucent, Cistron, as well as several other vendors.

CRCC> Could you please provide us with a complete list of the vendors that
CRCC> you have contacted about these vulnerabilities?

CRCC> We would like to use this time to contact our list of vendors and 
CRCC> receive replies. Also, we would like to be sure that vendors have 
CRCC> enough time to test and develop patches for these vulnerabilities. If 
CRCC> you have receive a reply from the vendors you have contacted, we would 
CRCC> be interested in receiving a copy of those messages as well.

CRCC> Thanks for you help and time on this. I hope we can get these problems 
CRCC> resolved in a timely and effective manner.

CRCC> Thank you,
CRCC>         Jason Rafail

CRCC> ==============================
CRCC> Member of the Technical Staff
CRCC> CERT Coordination Center
CRCC> Software Engineering Institute
CRCC> Carnegie Mellon University
CRCC> 4500 Fifth Avenue
CRCC> Pittsburgh, PA 15213
CRCC> 1-412-268-7090
CRCC> ==============================


CRCC> 3apa3a <address@hidden> writes:
>>------------6F1B020328F9DD28
>>Content-Type: text/plain; charset=us-ascii
>>Content-Transfer-Encoding: 7bit
>>
>>Hello,
>>
>>Advisory   below   is   about vulnerability in multiple RADIUS server. I
>>never tested Microsoft implementation of RADIUS server/client.
>>
>>I  want  to  release  advisory below in a week. I have no chance to test
>>Microsoft  RADIUS  implementation  from  Windows 2000 Server during that
>>time.  Almost  all  tested  RADIUS  servers of another vendors are found
>>vulnerable.
>>
>>Please  check  if  this vulnerability exists in your product. If so, you
>>can request additional time for fixing it.
>>
>>If you have some pieces of code taken from another RADIUS implementation
>>(Livingston, Ascend, Cistron, etc) you're probably vulnerable.
>>
>>You  can  use attached utility to check (It's for Unix, and compiled for
>>Windows  using Cygwin). All testing must be done from host registered as
>>valid  NAS  (this  test  program  doesn't  allow  you  to  spoof NAS IP.
>>Nevertheless it's possible to do it).
>>
>>
>>To test vulnerability #1:
>>
>>test_radius RADIUS_SERVER 1 100 MAX_PACKET_SIZE 10 1646 4
>>
>>where RADIUS_SERVER is ip of you host
>>MAX_PACKET is compiled maximum packet size, you can try different: 1024,
>>2048, 4096, 8192, etc
>>
>>To test vulnerability #2
>>
>>test_radius RADIUS_SERVER 11 20 311 0
>>
>>(malformed Microsoft MS-CHAP-Challenge packet)
>>
>>or
>>
>>test_radius RADIUS_SERVER 1 100 9 0
>>
>>(malformed CISCO Cisco-AVPair packet)
>>
>>
>>You  can  also  test  small  attributes  flood against your server (this
>>problem was reported on Bugtraq some time ago):
>>
>>test_radius RADIUS_SERVER 1 2 MAX_PACKET_SIZE 100000
>>
>>If  no  reply  on  testing  results  will  be  received during next week
>>advisory will be released in current form.
>>
>>
>>-=-=-=-=-=-=-
>>
>>Please note: you receive this note as software vendor or distributor.
>>
>>I'd like to report 2 different bugs present in almost all current RADIUS
>>servers.  Both bugs may be exploitable as a DoS against RADIUS server or
>>client.
>>
>>Both  vulnerabilities were discovered and fixed during internal audit of
>>FreeRADIUS project (http://www.freeradius.org).
>>
>>Please   update   FreeRADIUS  to  0.4  (or  current  snapshot)  in  your
>>distributions
>>
>>Severity   of   this   issue   is   marked   as  high  since  RADIUS  is
>>mission-critical  service,  many RADIUS clients and servers operate with
>>super-user credentials and exploitation is possible from spoofed IPs.
>>
>>Topic                   : 2 vulnerabilities in multiple RADIUS servers
>>                          and clients.
>>Author                  : 3APA3A <address@hidden>
>>Released                : December, 18 2001
>>Affected Software       : Lucent/Livingston RADIUS <= 2.1 (1)(2)
>>                          Cistron <= 1.6.4 (1)(2)
>>                          Cistron 1.6.5 (2)
>>                          XtRadius <= 1.1-pre1 (1)(2)
>>                          FreeRADIUS <= 0.3 (1)(2)
>>                          ICRadius <= 0.18.1 (1)(2)
>>                          YARD Radius <= 1.0.19 (1)(2*)
>>                          Ascend RADIUS <= 1.16 (1)
>>                          Merit RADIUS <= 3.6B2 (1)
>>                          GNU Radius <= 0.95 (1)
>>                          radiusclient <= 0.3.1 (1)
>>Not  tested             : Microsoft  RADIUS and a lot of RADIUS clients
>>Not affected            : FreeRADIUS 0.4
>>Risk                    : High (at least for few applications)
>>Remote                  : Yes
>>Exploitable             : Yes (at least for few applications)
>>SECURITY.NNOV advisories: http://www.security.nnov.ru/advisories
>>
>>
>>Description:
>>
>>(1)
>>
>>Digest Calculation Buffer Overflow Vulnerability
>>
>>This  bug was already reported http://www.securityfocus.com/bid/3530 but
>>this record has few flAws:
>>
>> 1. Original description of the bug is
>>   
>> http://www.securityfocus.com/cgi-bin/archive.pl?id=1&start=2001-12-15&end=2001-12-21&threads=0&address@hidden
>> 2. As you can see it is not specific to Cistron.
>>
>>Bug description:
>>
>>During digest calculation a string with shared secret is concatenated to
>>packet  received without checking target buffer. It makes it possible to
>>overflow  buffer  with  shared  secret  data. This can lead to Denial of
>>Service  against  server. This bug can only be exploited to execute code
>>remotely with RADIUS server (or RADIUS client) credentials (root in many
>>cases) only if attacker can change shared secret. I believe the only way
>>to  do  it  is social engineering (for example to write you provider who
>>does  RADIUS  proxy for you and to ask him to change a secret to desired
>>one).
>>
>>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);
>>
>>
>>There  are  also  few  product-specific  overflows  of  same  nature  in
>>different functions.
>>
>>Exploitation:
>>
>>In many cases this overflow is not exploitable due to specific of target
>>buffer  location in memory. This overflow occurs during validation check
>>of the packet. It means it's possible to exploit it with invalid spoofed
>>packed  and  there  is no need to send packet from valid NAS address and
>>use  valid  secret.  For  exploitation packet of maximal buffer size (or
>>near it) must be sent. Buffer size id different (RFC requires 4096 bytes
>>for  packet,  but it varies from ~2K in Cistron to 16K in Merit). Digest
>>calculated  if:  1. By RADIUS server then accounting packet received. 2.
>>By  RADIUS server then packet should be proxied 3. By RADIUS client then
>>response from server received This vulnerability can't be exploited with
>>Access-Request packet if RADIUS server doesn't proxies request.
>>
>>(2)
>>
>>Invalid  attribute  length  calculation  on  malformed  Vendor-Specific
>>attribute
>>
>>RADIUS  server  (or  client)  fails  to  check  a  Vendor-Length  inside
>>Vendor-Specific  attribute.  Vendor-Length  is  8 bit unsigned value, so
>>it's  impossible  to  overflow  the  buffer directly. But, Vendor-Length
>>shouldn't  be  <  2.  If  Vendor-Length  <  2  RADIUS server (or client)
>>calculates length as negative.
>>
>>Later, attribute length can be used in many functions.
>>
>>In  most  RADIUS  servers vulnerable function is rad_recv() or radrecv()
>>Vulnerable piece of code looks like
>>{
>>        ptr += 4;
>>        vendorlen = attrlen - 4;
>>        attribute = *ptr++ | (vendorcode << 16);
>>        attrlen   = *ptr++;
>>        attrlen -= 2;
>>        length -= 6;
>>}
>>
>>attrlen -= 2 can become negative.
>>
>>Also  another  bugs  of  same  nature present in pieces of code handling
>>different  Vendor-Specific attributes (for example code for USR-specific
>>attributes  is  different  but may have a same bug).
>>
>>*YARDRadius has vulnerability in handling USR-specific attributes only.
>>
>>Exploitation:
>>
>>In all vulnerable applications it's possible to cause DoS against RADIUS
>>server   with  malformed  Vendor-Specific  attribute.  Remote  execution
>>probably  is  not  possible because code executes memcpy() with negative
>>length leading to crash. DoS attack can be launched without knowledge of
>>shared  secret, so NAS address can be spoofed. This vulnerability can be
>>exploited with any type of packet.
>>
>>
>>-- 
>>http://www.security.nnov.ru
>>         /\_/\
>>        { , . }     |\
>>+--oQQo->{ ^ }<-----+ \
>>|  ZARAZA  U  3APA3A   }
>>+-------------o66o--+ /
>>                    |/
>>You know my name - look up my number (The Beatles)


-- 
~/ZARAZA
В расчетах была ошибка.  (Лем)