linux-kernel - Re: [PATCH 16/20] PKCS#7: Add an optional authenticated attribute to hold firmware name [ver #5]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5567C131.8050005@kernel.org>
Date:	Thu, 28 May 2015 18:30:25 -0700
From:	Andy Lutomirski <luto@...nel.org>
To:	David Howells <dhowells@...hat.com>,
	Luis Rodriguez <mcgrof@...e.com>
CC:	Matthew Garrett <mjg59@...f.ucam.org>, keyrings@...ux-nfs.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Kyle McMartin <kyle@...nel.org>,
	linux-wireless@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	Mimi Zohar <zohar@...ibm.com>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 16/20] PKCS#7: Add an optional authenticated attribute
 to hold firmware name [ver #5]

[resending with further gmane screwups fixed]

On 05/28/2015 08:48 AM, David Howells wrote:
> Modify the sign-file program to take a "-F <firmware name>" parameter.  The
> name is a utf8 string that, if given, is inserted in a PKCS#7 authenticated
> attribute from where it can be extracted by the kernel.  Authenticated
> attributes are added to the signature digest.
>
> If the attribute is present, the signature would be assumed to be for
> firmware and would not be permitted with module signing or kexec.  The name
> associated with the attribute would be compared to the name passed to
> request_firmware() and the load request would be denied if they didn't
> match.

This is insecure because PKCS#7 authenticated attributes are broken (see 
RFC2315 section 9.4 note 4).  You need to either require that everything 
have authenticated attributes or require that nothing have authenticated 
attributes.   Maybe this insecurity doesn't matter in practice, but I 
don't wouldn't want to bet on it.

On top of that, this is a ton of code to support something trivial.  And 
it requires an OID to be registered (ick).

Earlier you suggested just appending the signature purpose to the thing 
being signed.  What's wrong with that?  It's probably much less code, it 
doesn't require reviewing details of the godawful PKCS#7 spec, and it 
will continue working if and when someone adds a more sensible signature 
format.  And you could tear out PKCS#7 authenticated attribute support 
on top of it.

P.S.  Or you could stop using PKCS#7 if possible.  Holy crap, maybe it's 
a standard, but it's a standard that we don't actually have to follow 
and it *has trivial collisions by construction*.

For Pete's sake, there are already 1262 lines of code just implementing 
PKCS#7.  In contrast, the *entire* tweetnacl library, which uses better 
crypto and is actually correct (no built-in collisions) fits a complete 
signature implementation and the underlying crypto in barely half that 
many lines.  This is actually unfair to tweetnacl, as tweetnacl also 
includes an AEAD, which could be removed to shorten it by a decent amount.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/