Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ