Date: Tue, 4 Mar 2014 00:38:21 -0500 (EST) From: cve-assign@...re.org To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: CVE Request?: konqueror - https uses all ciphers, even weak ones -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> We received this bugreport for the KDE default webbrowser >> Konqueror: https://bugzilla.novell.com/show_bug.cgi?id=865241 > So the question becomes where do we draw the line? An example in which a CVE ID could be assigned is a product that sends a Client Hello message with an unintended omission of one strong cipher suite. For example, the product's documentation says that it supports all of the widely accepted 256-bit cipher suites, but an off-by-one error causes it to omit the very strongest one. This behavior is still a vulnerability, even though the product cannot use anything other than 256 bits. There's no "draw the line" number. In this Konqueror case, the question of whether it's a vulnerability or an opportunity for security hardening depends on the author's intention in writing the code that way, and on the threat model. The information sent to this list so far doesn't really clarify the root cause of the problem. One message perhaps suggested that, because of lack of developer time, the product doesn't use any non-default features of OpenSSL even if they would be security improvements. Another message mentioned "failed to find a module to configure the ciphers in the KDE configuration module jungle." So, there might be various possibilities, including: - the source code doesn't call SSL_CTX_set_cipher_list anywhere - the source code does call SSL_CTX_set_cipher_list if a cipher suite list is available, but the product doesn't actually look for that list in any part of the configuration - the product looks for a cipher suite list, but it is not parsed correctly, and therefore valid data is effectively ignored > 40/56 can be broken in single digit seconds We think this means your threat model is that there's an established session using 40-bit or 56-bit encryption, and then someone sniffs the network and does a successful brute-force search of the complete key space. Certainly this isn't a desirable outcome, but it doesn't seem to imply a vulnerability in Konqueror. If, for example, 40-bit encryption is in use, this means the server selected a 40-bit cipher suite. Four of the possible scenarios are: - It's an https server that's simply not capable of using anything other than 40 bits. Suppose that the server also supports http, which is very realistic. The Konqueror user needs to use this server for some reason, and would prefer not to have data intercepted. Here, it seems better for Konqueror to include 40-bit cipher suites in its Client Hello message, because the alternative is that the handshake will fail and the user will visit the analogous http:// URL instead. Use of 40-bit cipher suites is the right choice. It is not a vulnerability in Konqueror. - The server can support strong cipher suites, but is misconfigured to select only 40-bit cipher suites. This is a similar situation. If the user must use the server immediately (i.e., he doesn't have time to contact the server operator and ask for a reconfiguration), a 40-bit cipher suite is the right choice. - It's a rogue server that wants to launch an "attack" against Konqueror by making Konqueror use a 40-bit cipher suite. Ultimately, this attack has no real value. The server has access to the plaintext and can redistribute the plaintext to anyone. (We can probably ignore the possibility that a 40-bit session makes plaintext data available to an attacker on the client-side local network, and it might be expensive or risky for the server operator to transport the data there.) Similarly, it's not especially relevant that this has made it easy for another client to hijack a session and send different data. The server could simply pretend to receive the different data. - The server didn't intentionally select a 40-bit cipher suite, but (because a different security issue was exploited during the handshake) the communication channel ends up using 40-bit encryption. This is not ultimately the fault of Konqueror's use of 40-bit cipher suites. At the level of a policy decision designed to improve the entire https ecosystem, it may be preferable for 40-bit cipher suites to be dropped from all clients. This would, for example, encourage any remaining 40-bit-only server operator to upgrade. However, from the perspective of an individual user wishing to use Konqueror once to connect to one web server, it's not necessarily preferable. Because of this, the prospect of easily attackable 40-bit sessions doesn't, by itself, make this a Konqueror vulnerability. (Certainly it could be a security improvement if Konqueror clearly indicated to the user that the current https session is a 40-bit session. This would mainly be applicable in a case where KDE decided to intentionally support 40-bit sessions forever, ignoring the "improve the entire ecosystem" principle.) - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTFWUmAAoJEKllVAevmvmsnVcIAKrEtePZmgjJIYQiIWtU3MIZ JVHsEAJ+k//eRGt4Q9fspeZt2aRs4SBazvC7Rv9/mK/ZYBZy/ys0GtRJiClTPaHG Z/zZzttXhbZt+/25oCXHeNX+M944qZW1pwXS9I0QNttyu2NVt1pZqvYKvn7UYJeB lOWs53cM8C1+M50LE56puV+szUG/ovFsftEcNztbVnDJy8SUVud/Aio5POOX6Oyy QjrpfjFabwuDODBNawxpxL3hsL7/eI2+nI1L7udAzGhhQan6hV48/TSeeg26oWyN Nqg/GY5+KKAlVXljdevkTSf8QdjV2FlskBzkXJuh2gY7vJ4PhgOfkVX4CzeqJ9k= =g/ib -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.