[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#689991: marked as done (CUPS: error_log flooded due to AllowUser restriction)

Your message dated Thu, 5 Jul 2018 23:44:52 +0100
with message-id <05072018204049.2c16273f6fc1@desktop.copernicus.org.uk>
and subject line Re: Bug#689991: CUPS: error_log flooded due to AllowUser restriction
has caused the Debian Bug report #689991,
regarding CUPS: error_log flooded due to AllowUser restriction
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
689991: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689991
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cups
Version: 1.5.3-1
Severity: important
Tags: security

I've created a print queue with an
	AllowUser user1
option. When submitting a print job as user1 all goes as expected, but
if I submit it as some other user I see a flood of error messages appear
(observed rates: 375-500 Hz, depending on the client) in
/var/log/cups/error_log:

E [08/Oct/2012:20:31:23 +0200] Returning IPP client-error-not-authorized for Create-Job (ipp://xxx.yyy.zzz.ttt:631/printers/test1) from aaa.bbb.ccc.ddd

cupsd consumes significant amounts of CPU time while the client is trying
to submit the job. Both the log flood and the CPU consumption stop as soon
as I cancel the print job on the client.

Conclusion: use of AllowUser/DenyUser can lead to (often inadvertent) denial
of service attacks.

A packet capture shows a loop of:

C: POST /printers/test1 HTTP/1.1
   [...]
   printer-uri ipp://xxx.yyy.zzz.ttt:631/printers/test1
   requesting-user-name user2
   [...]
   job-originating-user-name user2
   [...]
S: HTTP/1.1 100 Continue
S: HTTP/1.1 200 OK
   [...]
   status-message Not allowed to print

all in the same TCP connection. 

The clients I tested with were running cups 1.5.3-1 (wheezy)
and 1.5.3-0ubuntu4 (precise).

--- End Message ---
--- Begin Message --- 
On Mon 08 Oct 2012 at 21:47:46 +0200, Sergio Gelato wrote:

> Package: cups
> Version: 1.5.3-1
> Severity: important
> Tags: security
> 
> I've created a print queue with an
> 	AllowUser user1
> option. When submitting a print job as user1 all goes as expected, but
> if I submit it as some other user I see a flood of error messages appear
> (observed rates: 375-500 Hz, depending on the client) in
> /var/log/cups/error_log:
> 
> E [08/Oct/2012:20:31:23 +0200] Returning IPP client-error-not-authorized for Create-Job (ipp://xxx.yyy.zzz.ttt:631/printers/test1) from aaa.bbb.ccc.ddd
> 
> cupsd consumes significant amounts of CPU time while the client is trying
> to submit the job. Both the log flood and the CPU consumption stop as soon
> as I cancel the print job on the client.
> 
> Conclusion: use of AllowUser/DenyUser can lead to (often inadvertent) denial
> of service attacks.
> 
> A packet capture shows a loop of:
> 
> C: POST /printers/test1 HTTP/1.1
>    [...]
>    printer-uri ipp://xxx.yyy.zzz.ttt:631/printers/test1
>    requesting-user-name user2
>    [...]
>    job-originating-user-name user2
>    [...]
> S: HTTP/1.1 100 Continue
> S: HTTP/1.1 200 OK
>    [...]
>    status-message Not allowed to print
> 
> all in the same TCP connection. 
> 
> The clients I tested with were running cups 1.5.3-1 (wheezy)
> and 1.5.3-0ubuntu4 (precise).

wheezy is unsupported on Debian, so closing this report.

Further investigations should be conducted with an unstable release of
cups on client and server.

Regards,

Brian.

--- End Message ---
Reply to: