linux-kernel - Re: [GIT PULL] Load keys from signed PE binaries

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: <CAAMvbhF5MRWXZGfLH-GSjSBExrCu48=rz4UGrXwWxHZZY_rcXA@mail.gmail.com>
Date:	Wed, 27 Feb 2013 11:49:34 +0000
From:	James Courtier-Dutton <james.dutton@...il.com>
To:	Alexander Holler <holler@...oftware.de>
Cc:	ownssh <ownssh@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] Load keys from signed PE binaries

On 27 February 2013 11:27, Alexander Holler <holler@...oftware.de> wrote:
> Am 27.02.2013 11:17, schrieb James Courtier-Dutton:
>
>
>> 3) Trust based on date. I trust everything from X that I put on my
>> system 2 weeks ago, but one week ago X got hacked, so don't trust
>> anything new from them until the hack has been stopped and the
>> revokation/correction steps have been completed.
>> E.g. the Bit9 case, where malware was able to be signed.
>
>
> Which date? In reality dates are (mostly) defined as fixed points, but
> computers just don't have such.
>
> E.g. currently you can't use modsign based on X.509 certificates if the date
> comes through USB, because modsign tries to load the certificate before
> before the USB stack comes up, which ends up with invalid dates (Not
> Before).
> And changing the system date isn't that hard for an attacker if he is
> already able to do other bad things.
>

Maybe date was not a good example.
I think a single chain of trust is risky.
Using multiple signatures on the same binary is better.
e.g. Redhat have signed it, but only load the module if both redhat
and Bit9 have signed it.
In this case, the risk it mitigated, as both Redhat and Bit9 have to
be hacked for the malware to get through.
Now, if a local administrator created a new signing key each time they
installed updates, and the system checked that both the redhat
signature and the local administrator signature were valid before
loading the module, this would give a form of signing based on date.
(the install date)
The local administrator could then quickly revoke the keys for a
particular day, and not have to wait for Redhat to revoke their keys.
--
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/