Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign updenial of service hole in CUPS #863
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
michaelrsweet
Aug 21, 2004
Collaborator
CUPS.org User: ame.acm
My name is Alvaro Martinez Echevarria, by the way (I forgot to sign :).
|
CUPS.org User: ame.acm My name is Alvaro Martinez Echevarria, by the way (I forgot to sign :). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
michaelrsweet
Aug 23, 2004
Collaborator
CUPS.org User: mike
After researching the issue, it looks like the == 0 check was added as extra insurance when another sendto() issue was fixed WRT downed interfaces, so this patch is good.
Thanks, will be part of the 1.1.21rc2 release but unannounced until Sept 1st.
|
CUPS.org User: mike After researching the issue, it looks like the == 0 check was added as extra insurance when another sendto() issue was fixed WRT downed interfaces, so this patch is good. Thanks, will be part of the 1.1.21rc2 release but unannounced until Sept 1st. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
michaelrsweet
Aug 23, 2004
Collaborator
CUPS.org User: mike
Fixed in CVS - the anonymous CVS repository will be updated at midnight EST.
|
CUPS.org User: mike Fixed in CVS - the anonymous CVS repository will be updated at midnight EST. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
michaelrsweet
Sep 8, 2004
Collaborator
"cups-zero-len-udp-dos.patch":
--- cupsys-1.1.20final+rc1/scheduler/dirsvc.c.OLD 2004-05-27 11:04:32.000000000 -0700
+++ cupsys-1.1.20final+rc1/scheduler/dirsvc.c 2004-08-20 19:20:08.000000000 -0700
@@ -1093,7 +1093,7 @@
int auth; /* Authorization status /
int len; / Length of name string /
int bytes; / Number of bytes left */
- char packet[1540], /* Broadcast packet */
- char packet[1541], /* Broadcast packet /
*pptr; / Pointer into packet /
struct sockaddr_in srcaddr; / Source address /
char srcname[1024]; / Source hostname */
@@ -1118,8 +1118,8 @@
*/
len = sizeof(srcaddr);
- if ((bytes = recvfrom(BrowseSocket, packet, sizeof(packet), 0,
-
(struct sockaddr *)&srcaddr, &len)) <= 0) - if ((bytes = recvfrom(BrowseSocket, packet, sizeof(packet)-1, 0,
-
{(struct sockaddr _)&srcaddr, &len)) < 0)
/_- "Connection refused" is returned under Linux if the destination port
|
"cups-zero-len-udp-dos.patch": --- cupsys-1.1.20final+rc1/scheduler/dirsvc.c.OLD 2004-05-27 11:04:32.000000000 -0700
len = sizeof(srcaddr);
|
michaelrsweet commentedAug 21, 2004
Version: 1.1.20
CUPS.org User: ame.acm
I've found that it's possible to disable browsing in CUPS by
sending an empty UDP datagram to port 631 where cupsd is
running. For example:
evil.com:/# nmap -sU -p 631 naive.org
Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-08-20 18:33 PDT
Interesting ports on naive.org (10.0.0.1):
PORT STATE SERVICE
631/udp closed unknown
Nmap run completed -- 1 IP address (1 host up) scanned in 1.137 seconds
Which results in the following two lines at /var/log/cups/error_log
in naive.org:
E [20/Aug/2004:18:29:33 -0700] Browse recv failed - No such file or directory.
E [20/Aug/2004:18:29:33 -0700] Browsing turned off.
At that point, cupsd stops listening in the UDP port.
If this happens when cupsd is starting, and depending on the
configuration, the attacked host may never see any remote
printers. Similarly, a running cupsd will not see any future
remote printer changes.
I've confirmed this behaviour under Debian/sid (cupsys version
1.1.20final+rc1-5), but the guilty lines of code seem to be the
same for all the versions that I've checked (the last release
from cups.org, 1.1.21rc1, as well as Debian stable, 1.1.14).
I've attached a patch that fixes the problem.
The code was wrongly interpreting recvfrom() == 0 as an error. By
the way, there is another little error in the code that I've also
corrected: an off-by-one stack buffer overflow that happens when
a big UDP datagram is received. I doubt that it's exploitable,
but you never know.