Bug 680212 - VUL-1: cups: denial of service via cupsDoAuthentication when GSSAPI is not enabled
VUL-1: cups: denial of service via cupsDoAuthentication when GSSAPI is not en...
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: General
All SLES 11
: P4 - Low : Minor
: ---
Assigned To: Security Team bot
Security Team bot
maint:released:sle11-sp1:43331 CVSSv2...
Depends on:
  Show dependency treegraph
Reported: 2011-03-16 16:28 UTC by Marcus Meissner
Modified: 2018-10-19 18:07 UTC (History)
2 users (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2011-03-16 16:28:01 UTC
is public, from cve db


The cupsDoAuthentication function in auth.c in the client in CUPS before 1.4.4, when HAVE_GSSAPI is omitted, does not properly handle a demand for authorization, which allows remote CUPS servers to cause a denial of service (infinite loop) via HTTP_UNAUTHORIZED responses. 

we use --enable-gssapi always, so I think this does not affect our prebuilt packages.
Comment 1 Johannes Meixner 2011-03-17 10:52:04 UTC
The matching CUPS STR for CVE-2010-2432 is

openSUSE 11.4 has cups-1.4.6 which is safe
openSUSE 11.3 has cups-1.4.4 which is safe

openSUSE 11.2 has cups-1.3.11
SLE11 has cups-1.3.9
SLE10 has cups-1.1.23
SLE9 has cups-1.1.20

We use "./configure ... --enable-gssapi" in cups.spec for

But we do not use "./configure ... --enable-gssapi" in cups.spec for

If cups is compiled without HAVE_GSSAPI and is used with a server
that requires authorization, the client gets into an infinite loop.

As far as I understand this together with comment #0,
it means that the server lets the client go into an infinite loop
so that the denial of service happens at the client program
which the user of the client program could abort.

If my understanding is right, I think it is only a minor issue and
I like to ask if I should fix it nevertheless for SLE10 and SLE9
or if we may do nothing in this case?
Comment 2 Marcus Meissner 2011-03-17 14:20:18 UTC
sles9 - unimportant for denial of service issues, no fix required.

sles10 - i would put it on the planned update list.

I am not sure if the "HAVE_GSSAPI" part of the description is correct after reviewing the code, it seems the endless retries could also happen with HAVE_GSSAPI.
Comment 3 Johannes Meixner 2011-03-17 14:53:58 UTC
please put it on the planned update list.
Comment 4 Swamp Workflow Management 2011-07-05 11:42:35 UTC
The SWAMPID for this issue is 42066.
This issue was rated as low.
Please submit fixed packages until 2011-08-02.
Also create a patchinfo file using this link:
Comment 10 Johannes Meixner 2011-09-16 14:32:01 UTC
Reopened for further processing by the security team.
Comment 13 Sebastian Krahmer 2011-10-17 09:31:22 UTC
Comment 14 Swamp Workflow Management 2011-10-17 20:00:49 UTC
Update released for: cups, cups-client, cups-debuginfo, cups-debugsource, cups-devel, cups-libs, cups-libs-32bit, cups-libs-x86
SLE-DEBUGINFO 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11-SP1 (i386, x86_64)
SLE-SDK 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11-SP1 (i386, ia64, ppc64, s390x, x86_64)
SLES4VMWARE 11-SP1 (i386, x86_64)