[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
