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

michaelrsweet opened this issue Aug 21, 2004 · 4 comments

denial of service hole in CUPS #863

michaelrsweet opened this issue Aug 21, 2004 · 4 comments


Copy link

@michaelrsweet michaelrsweet commented Aug 21, 2004

Version: 1.1.20 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: nmap -sU -p 631

Starting nmap 3.55 ( ) at 2004-08-20 18:33 PDT
Interesting ports on (
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
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, 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.

Copy link
Contributor Author

@michaelrsweet michaelrsweet commented Aug 21, 2004 User: ame.acm

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

Copy link
Contributor Author

@michaelrsweet michaelrsweet commented Aug 23, 2004 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.

Copy link
Contributor Author

@michaelrsweet michaelrsweet commented Aug 23, 2004 User: mike

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

Copy link
Contributor Author

@michaelrsweet michaelrsweet commented Sep 8, 2004


--- 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
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant