Date: Mon, 10 Mar 2014 13:19:46 -0700 From: Alex Gaynor <alex.gaynor@...il.com> To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: When is broken crypto a vulnerability? 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@...eck.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@...eck.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ