oss-sec mailing list archives
Re: When is broken crypto a vulnerability?
From: Alex Gaynor <alex.gaynor () gmail com>
Date: Mon, 10 Mar 2014 13:19:46 -0700
When thinking about this issue, I like to refer to: https://glyph.twistedmatrix.com/2005/11/ethics-for-programmers-primum-non.htmlany time the behavior of the program violates the users intent in a way which compromises their security, that's a security issue. To that end, any of a-d, IMO, ought to quality for a CVE, the only acceptable way to expose functionality like this is LegacyObviouslyBrokenZipEncryption. Alex On Mon, Mar 10, 2014 at 11:58 AM, Hanno Böck <hanno () hboeck de> wrote:
Hi, I'm currently looking into the issue of ZIP encryption and I'm asking myself what should be considered a vulnerability. Quick summary: The situation is rather horrible. There is a "legacy" ZIP encryption that has been broken since 1994. There are two competing standards for AES encryption on ZIP files, one by PKWARE, the other by WinZip (although the WinZip one is used by pretty much everybody and the PKWARE one only by PKZIP). The 1994 attack is a known plaintext attack. There's an improved attack since 2001 that works in many cases without a known plaintext, however there's no public source implementing that. Some commercial tools implement this attack. Now there are all kinds of applications doing one of the following things: a) Just support the legacy "encryption" without any indication that it's broken. b) Provide an option to use AES, but they don't use it and still create legacy "encryption". c) Default to legacy "encryption" without any indication that it's broken, provide an option for AES encryption. d) Default to AES encryption, provide legacy "encryption" under various names like ZipEncrypt, ZIP 2.0 or similar that give no indication that it's broken. I think it should be noncontroversial that b) is a vulnerability and thus should get a CVE. Any disagreement here? What do you think about the others? IMHO it's always inacceptable to provide an "encryption" option that doesn't really encrypt. I could accept it if applications provide this as a compatibility option when there's a clear sign to the user that it's not secure (like calling it "ZipCrypto(insecure)" or "insecure crypto" or something alike). Although I'd prefer if at least enduser oriented apps wouldn't support insecure encryption at all. However, are these vulnerabilities? Should they get CVEs? I'm not sure, but I'd tend to give at least the a) and c) case also CVEs. We have to keep in mind that we're not talking about "theoretically broken/weak" crypto, we're talking about "you can buy software that will give you the password"-broken. Opinions wanted. (I'm sending this to oss-security, it affects all kinds of opensource applications, but it obviously also affects non-opensource applications) cu, -- Hanno Böck http://hboeck.de/ mail/jabber: hanno () hboeck de GPG: BBB51E42
-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084
Current thread:
- When is broken crypto a vulnerability? Hanno Böck (Mar 10)
- Re: When is broken crypto a vulnerability? Alex Gaynor (Mar 10)
- Re: When is broken crypto a vulnerability? Chris Palmer (Mar 10)
- Re: When is broken crypto a vulnerability? cve-assign (Mar 10)
- Re: When is broken crypto a vulnerability? Hanno Böck (Mar 10)
- Re: Re: When is broken crypto a vulnerability? Chris Palmer (Mar 10)
- Re: When is broken crypto a vulnerability? cve-assign (Mar 10)
- Re: When is broken crypto a vulnerability? cve-assign (Mar 11)
- Re: When is broken crypto a vulnerability? Hanno Böck (Mar 10)
- Re: When is broken crypto a vulnerability? Alex Gaynor (Mar 10)