-
Notifications
You must be signed in to change notification settings - Fork 464
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
CUPS needs a way to control the use of cipher suites and protocol versions #4476
Comments
CUPS.org User: alokispaney I am using Centos 6 for running cups. |
CUPS.org User: mike Changing the title; this is not a CUPS vulnerability per-se but an issue in the underlying TLS toolkits it uses. And quite frankly a set of cipher suites that is being deprecated by the TLS WG in the IETF and something that is typically a configuration option doesn't qualify as a general security vulnerability in a particular piece of software... Since each toolkit provides different ways to override their default cipher suites, we have not yet exposed a configuration directive to configure the cipher suites. And unlike SSLv2 which we we able to disable across the board in CUPS 1.2 or so, RC4 remains the most secure algorithm available on older releases of Windows so at this point we are not comfortable disabling it by default without having a way to turn it back on... Will use this bug to track the upstream changes in CUPS. In the meantime, I would contact your Linux distributor for assistance on getting a fix for CUPS 1.4.x. |
CUPS.org User: alokispaney Please do let me know what details from system you are looking for to provide your assistance. I am the server owner with root privledge. |
CUPS.org User: mike Due to POODLE, I am bumping the priority of this bug to 4. In addition to cipher suites, we need to allow disabling/enabling protocol versions. Apache mod_ssl uses SSLCipherSuite and SSLProtocol directives for this; not sure if we want to use these with their syntax as-is, but that is the functionality required. |
CUPS.org User: mike Upon further thought and examination of the TLS APIs we are working with, we should just bring back the SSLOptions directive that was added in CUPS 1.4 and subsequently dropped in 2.0 in the TLS update. Previously the only values were "None" and "NoEmptyFragments", the latter only being available/used for OpenSSL. New values will be "AllowRC4" and "AllowSSL3": SSLOptions [option ... option] The SSLOptions directive specifies additional SSL/TLS protocol options to use for encrypted connections. The default is "None" which provides the most secure mode supported by the operating system. Security can be relaxed using the "AllowRC4" and "AllowSSL3" options which allow negotiation of RC4 cipher suites and the SSL 3.0 protocol, respectively. |
CUPS.org User: mike Fixed in Subversion repository. The attached patch brings back the SSLOptions direct for cupsd.conf and adds it to client.conf (but just the system-wide one in /etc/cups). "AllowRC4" re-enables RC4 cipher suites, and "AllowSSL3" re-enabled SSL 3.0 support. |
"str4476.patch": Index: doc/help/man-client.conf.html--- doc/help/man-client.conf.html (revision 12210) Index: doc/help/man-cupsd.conf.html--- doc/help/man-cupsd.conf.html (revision 12210) Index: cups/tls-sspi.c--- cups/tls-sspi.c (revision 12210)
/*
@@ -897,6 +906,17 @@ /*
+/*
@@ -1727,12 +1747,44 @@ /*
+#ifdef SP_PROT_TLS1_2_SERVER
+#else
/_
/*
@@ -41,6 +49,7 @@ @@ -973,6 +982,17 @@ /*
+/*
@@ -1033,10 +1053,109 @@
+# if USE_SET_ENABLED_CIPHERS
if (!error && http->mode == HTTP_MODE_CLIENT)
|
"23-20231096.patch": /------------------------------------------------------------------------------------------------- context = SSL_CTX_new(SSLv23_server_method());
ifdef HAVE_LIBSSLcontext = SSL_CTX_new(SSLv23_client_method());
bio = BIO_new(_httpBIOMethods()); |
CUPS.org User: twaugh.redhat +#define _HTTP_TLS_ALLOW_RC4 1 /* Allow RC4 cipher suites _/ Should they be different values? |
CUPS.org User: mike Indeed, fixed in TOT. |
CUPS.org User: twaugh.redhat
Also I think that should read "NORMAL:+VERS-TLS-ALL:-VERS-SSL3.0" (VERS-TLS-ALL needs a + in front), or even better: "NORMAL:-VERS-SSL3.0". |
CUPS.org User: twaugh.redhat Shouldn't the "Upgrade" HTTP field contain "SSL/3.0" if _HTTP_TLS_ALLOW_SSL3 is set in tls_options? In which case, scheduler/conf.c will need to call _httpTLSSetOptions() to tell it what SSLOptions is, and we'll need to ensure _HTTP_TLS_ALLOW_SSL3==CUPSD_SSL_ALLOW_SSL3. |
CUPS.org User: mike SSL was never supported for HTTP Upgrade (only TLS 1.0 and higher). |
CUPS.org User: twaugh.redhat So in older versions it was advertised in error? e.g. this change from 2012: @@ -3690,7 +4714,7 @@ http_send(http_t http, / I - Connection to ser
Also, a usersys.c question: shouldn't cupsSetEncryption() also call _cupsSetDefaults() if the defaults haven't yet been set? i.e. something like: @@ -257,6 +258,9 @@ cupsSetEncryption(http_encryption_t e) /
cg->encryption = e; if (cg->http) |
CUPS.org User: mike Tim, older versions advertising SSL were an error. And since the defaults are set independently as needed (and if there is an issue there, please file a separate, new bug for it, thanks!) we should not need to set them in cupsSetEncryption, just in cupsEncryption (which gets the current value...) |
CUPS.org User: panchami_sanjeev This patch solves POODLE Vulnerability by disabling SSLv3 in CUPS. This fix is specific to solaris , which is using cups 1.4.5 Patch file is attached. |
Version: 1.4.2
CUPS.org User: alokispaney
Summary:
This routine search for weak SSL ciphers offered by a service.
Vulnerability Insight:
These rules are applied for the evaluation of the cryptographic strength:
,!otocol.
,!thods
and therefore considered as weak.
,!.
,! 13 attacks
. . . continues on next page . . .
2 RESULTS PER HOST 35
. . . continued from previous page . . .
,! medium
Solution:
The configuration of this services should be changed so
that it does not support the listed weak ciphers anymore.
Weak ciphers offered by this service:
SSL3_RSA_RC4_128_MD5
SSL3_RSA_RC4_128_SHA
TLS1_RSA_RC4_128_MD5
TLS1_RSA_RC4_128_SHA
How to fix it in cups ?
The text was updated successfully, but these errors were encountered: