Date: Sun, 22 Aug 2004 14:48:32 +0200
From: Martin Schulze <joey@infodrom.org>
To: vendor-sec@lst.de
Subject: [vendor-sec] CAN-2004-0558: DoS in CUPS
Parts/Attachments:
   1 Shown    115 lines  Text
   2   OK      22 lines  Text
----------------------------------------

Hi,

We've been informed about a DoS situation in CUPS:

| From: Alvaro Martinez Echevarria <ame@acm.org>
| To: security@debian.org
| Cc: cups-support@cups.org
| Subject: denial of service hole in CUPS
| X-Folder: debian-security-private@lists.infodrom.org
| 
| Hi there,
| 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).

| 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.
| Regards,
|
| PS: btw, if this ever gets to be some kind of advisory, Debian or
| otherwise, I'd appreciate a mention to my finding/fixing this; in
| any case, please don't include my (unedited) email address, as I
| am getting more than enough spam already :)...

The proposed patch is attached.

However, upstream (Michael Sweet <mike@easysw.com>) is not happy with it:

| The code was wrongly interpreting recvfrom() == 0 as an error. By

> recvfrom() will return 0 when the network goes down; when this
> happens, if we don't close the socket CUPS will consume 100% CPU
> on some platforms.

Unfortunately this will be part of the release candidate published
tomorrow.  And there is not yet an official patch available.
Upstream is quite stubborn about coordinating an update:
Michael Sweet wrote:
> Martin Schulze wrote:
> >...
> >ARGS.  That would be quite bad since in that case no vendor could roll
> >out updates in time.
>
> We will omit the change info from the CHANGES.txt file and release
> announcement, but not the fix itself (someone would need to look
> at the code to see the change, and we will use a non-descript CVS
> commit message)
>
> >Does this fix has to be part of the rc2?  Couldn't it be added afterwards
> >and be published on September 6th?
>
> Yes, it MUST be part of the release candidate - that's the whole
> purpose of a release candidate, to test and maintain quality!  We
> have a process in place, and we mean to follow it.
>
> We WILL NOT withhold a fix, and we will not do a post-1.1.21 release
> for your convenience.
>
> >I mean... It's Sunday already, you're talking about Monday and don't
> >have the fix handy already.  That's a bit scary to me...
>
> Be scared if you want, but scared does not make the problem go
> away or get a fix any faster.
>
> First, we do have a candidate patch, and second, this isn't
> a security problem but a localized DoS nuisance that is easily
> tracked to the source.
>
> The only question is whether the patch will revive an old issue
> with downed network interfaces causing 100% CPU usage, and that
> only requires a small amount of research on our part.
>
> Had my network link been working on Friday, we likely would have
> done the 1.1.21rc2 release then.

The issue is also <http://www.cups.org/str.php?L863> which is not
listed in the overview page.

Regards,

       Joey