Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

denial of service hole in CUPS #863

Closed
michaelrsweet opened this issue Aug 21, 2004 · 4 comments
Closed

denial of service hole in CUPS #863

michaelrsweet opened this issue Aug 21, 2004 · 4 comments
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

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.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: ame.acm

My name is Alvaro Martinez Echevarria, by the way (I forgot to sign :).

@michaelrsweet
Copy link
Collaborator Author

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.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Fixed in CVS - the anonymous CVS repository will be updated at midnight EST.

@michaelrsweet
Copy link
Collaborator Author

"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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant