Bugzilla – Bug 61517
VUL-0: CVE-2004-0923: CUPS reveals windows passwords in logfiles
Last modified: 2021-10-14 14:37:51 UTC
From vendor-sec: Apple received on Sep 23rd an external report of CUPS logging "Windows Printing" passwords into its error log file. The reporter also CC'ed CERT. We do not have agreed upon attribution information at this time. I didn't realize until today that what we have fixed is a standard part of CUPS. The following "Software Trouble Report" has been filed with CUPS. http://www.cups.org/str.php?L920 CAN-2004-0923 has been assigned for this issue. We are about to release a Security Update (2004-09-30), but will hold off announcing information on this vulnerability until others are ready. We propose a release date of October 11th at 1:00pm Pacific Time. (This has not yet been agreed to by the CUPS folks) ------------------------------------------------------------------------ Comment by Klaus Singvogel: This can also prevented in removing read/execute rights for other on directory /var/log/cups (chmod o=- /var/log/cups). So I don't know, if we really need to fix this problem.
<!-- SBZ_reproduce --> Print to a windows machine, which requires a username and password. Have a look at /var/log/cups/error_log for password logged in clear text.
Created attachment 24259 [details] sanitize.patch This patch modifies logging calls only. Looks good in my point of view.
CUPS developer team rejected above patch and want to write a cleaner patch for this issue. They also say that the password is only revealed, if LogLevel is changed to debug or debug2 (default is info). Having a LogLevel=debug reveals even more passwords into the logfile; any hardcoded password in a URI is affected. Even more, then it happens even with Basic passwords (authentification mechanism at CUPS server). This is done with intention (debugging purpose) and is written into the (distributed) documents. Look here: file:/usr/share/doc/packages/cups/ssr.html I'm in doubt now, if we should really make an update: a) a default configuration is not affected, b) its documented, and c) debugging gets harder. Can be fixed either by removing access bits on log-directory and read bits on logfiles.
From: Michael Sweet <mike@easysw.com> To: vendor-sec@lst.de Cc: Jim Lovell <jlovell@apple.com>, product-security@apple.com Subject: [vendor-sec] Re: CAN-2004-0923 Device URIs containning username & +password end up in error_log This issue is also CUPS STR #920, accessible at the following URL: http://www.cups.org/str.php?L920 This STR is currently hidden from normal public view but is accessible by the direct link. I have attached an official patch against CUPS 1.1.21 (str920.patch) which will also be included in the forthcoming 1.1.22rc1 release. A final 1.1.22 release will be made in 2 weeks (Monday, October 18th) assuming that no other priority 4 or 5 STRs are reported in the CUPS software before then. FWIW, DEVICE_URI exposure is a well known issue that is documented in the CUPS Software Security Report and Software Administrators Manual, available in the CUPS source code and on-line at: http://www.cups.org/documentation.php Note the the patch only eliminates the authentication information in the device URI that is logged in the error_log file; it does NOT eliminate the URI from the environment and process table, which is why we recommend that system administrators do not hardcode authentication information in device URIs in the first place...
"Michael Sweet 16:09 Sep 30, 2004 Do you have an ID number or some other identifier for me to use when I contact them? I think we can do a 1.1.22 release candidate on Tuesday next week, which would mean a final release on the 17th. We won't be treating this as a vulnerability, as the same device URI information has been available via the environment and argv[0] (all visible via the "ps" command) and has been documented for a very long time."
After talking to Klaus, and in regards to Michaels comments (and every user being able to see argv[0] anyway), I lay this issue to rest as a non-issue.
*** Bug 64820 has been marked as a duplicate of this bug. ***
CVE-2004-0923: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:P/I:N/A:N)