linux-kernel - Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALCETrWXbBDJTadj0vHT0v5mMWJ6Uop_nMJn02Wa5EZFUbOgUw@mail.gmail.com>
Date:	Thu, 21 May 2015 16:09:00 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	David Howells <dhowells@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Michal Marek <mmarek@...e.cz>,
	Matthew Garrett <mjg59@...f.ucam.org>, keyrings@...ux-nfs.org,
	Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	LSM List <linux-security-module@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [PATCH 0/8] MODSIGN: Use PKCS#7 for module signatures [ver #4]

On Thu, May 21, 2015 at 4:01 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
> On Thu, May 21, 2015 at 03:47:49PM -0700, Andy Lutomirski wrote:
>> On Thu, May 21, 2015 at 3:31 PM, Luis R. Rodriguez <mcgrof@...e.com> wrote:
>> >
>> > Well as good as you are in 10 years we'll have better ones. So when
>> > module signature went into the kernel the real expectation should have
>> > been:
>> >
>> > This code looks good now but is going to be complete shit and
>> > breakable a few years from now.
>> >
>> > Hence my first implicit and now explicit claims on dog and pony shows.
>> > Best thing we can do IMHO is to just allow us to replace stupid human
>> > code with better human code later, and eventually hopefully better AI
>> > code, and so on. Since you don't have time for a real replacement
>> > maybe what we can do is at least document / target / agree for what
>> > pipe dream we want and shoot for it with time. Hopefully folks will
>> > find time to implement it.
>>
>> I disagree.  I'm a firm believer in security proofs.  While I'm not
>> trained in formal crypto proofs, I can sketch out a proof of why a
>> system that properly tags its signatures is secure against a
>> reasonable threat model.  I can also show why that proof wouldn't work
>> for a scheme without tags, and I can demonstrate the actual weakness
>> in a scheme without tags.
>>
>> In ten years, the only reason a scheme that I say looks good would be
>> because (a) I screwed up, (b) an underlying assumption is wrong, or
>> (c) the implementation is subtly wrong.  In particular, it won't fail
>> because I'm insufficiently clever.
>>
>> A real professional expert would be less likely to screw up.
>>
>> (For reference, I wrote an actual doctoral thesis involving crypto.)
>
> OK, I think what I mentioned still holds:
>
> these premises must hold true for a period of time, and provided
> you have all information. You cannot have all the information, so
> the "threat model" depends on the reviewer, and the information they
> have access to. So, still its still a dog and pony show, at least
> a temporal one or one with a set of clauses.
>
>> > In the meantime should that block current dog and pony show trading? I
>> > don't think so.
>>
>> Yes, since I can demonstrate the actual weakness without tags,
>
> But you don't want to do the work to provide a better replacement?

Hell no.  At least not until someone convinces me that I want any of
this on any system I build.  Thus far I'm unconvinced.

Meanwhile, the threat model seems to be that you don't want an
attacker not in possession of a distro-trusted or UEFI-trusted private
key to cause the kernel to load incorrect firmware into a device or
incorrect regulatory data.

Without tagging the purpose of the signed file, you simply don't have
a cryptographic guarantee of that.  The bad guy can load something
else that was signed for an entirely different purpose into the wrong
device, possibly crashing it, causing buffer overflows because the
format is wrong, or doing any number of other bad things.

>
>> and
>> crypto is notoriously hard to fix once done poorly and there's a great
>> history of obviously-theoretically-weak systems being meaningfully
>> attacked in the real world.  See, for example, every single old
>> SSL/TLS cipher.  (And yes, the crypto community knew what was wrong in
>> theory and how to fix it when the protocol was designed.  People just
>> didn't pay attention.)
>
> Its a fair argument, but still -- we have the vaporware problem.

If you write crypto verification code for firmware and I review it,
and your code doesn't cryptographically protect it adequately, I'll
say that in my review.  That's all.

--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/