On Thu, Feb 28, 2013 at 10:51:15PM +0000, Matthew Garrett wrote:
> On Thu, Feb 28, 2013 at 11:48:06PM +0100, Jiri Kosina wrote:
>
> > Let me formulate my point more clearly -- Microsoft very likely going to
> > sign hello world EFI PE binary, no matter the contents of .keylist
> > section, as they don't give a damn about this section, as it has zero
> > semantic value to them, right?
> >
> > They sign the binary. By signing the binary, they are *NOT* establishing
> > cryptographic chain of trust to the key stored in .keylist, but your
> > patchset seems to imply so.
>
> Mr Evil Blackhat's binary is then a mechanism for circumventing the
> Windows trust mechanism, and as such his account is subject to
> termination and his binary can be added to dbx.
Why?
Let's take a look on what would happen in this scenario:
A PE binary, from Mr. Blackhat, doing nothing, in general, but
containing a key in a section, was signed by MS on the grounds that the
binary isn't harmful.
By issuing the signature, MS is attesting that the binary is safe, but
isn't saying anything about the data (key) embedded in it. It doesn't
say the key comes from a trusted party. It just says "this isn't
malware", and that's what their tools verify.
Your shim loader (signed by MS) loads your Linux kernel.
Your Linux kernel, then, based on the key-in-PE model decides to trust
the key, although nobody really said it's to be trusted.
Mr. Blackhat then can load his i_own_your_ring0.ko module signed by his
key on your system, having obtained root access previously.
You call Microsoft, telling them what Mr. Blackhat has done.
They now can:
a) Do what you want: Disable Mr. Blackhat's account and revoke the hash
of his binary.
But also:
b) Say, "oh well, we're sorry this kills your security model, but it's
enough for us that you already fully booted Linux to worry about Windows
security, this affects only your distribution and we don't care".
c) Decide your security model is flawed, because you're abusing their
signature process to mean something else from what they intended and
revoke your shim hash instead.
And I don't think you can rely on MS doing 'a'. Particularly when there
will be a large number of key-in-PE binaries signed by them at that
point, with them not being able to tell by any analysis which of them
are evil and which not.
I would even say b) is most likely.
> We'd check the binary hash against dbx and refuse to load it on
> systems that have received the update, and Mr Evil Blackhat would have
> to find a new bunch of identity documents to create a new account to
> repeat the process.
Yes, from the point it gets blacklisted, it's fairly clear. You're
forced to reboot, but under the Secure Boot model, you have to do that
on any system that used code whose hash has been revoked.
--
Vojtech Pavlik
Director SuSE Labs
On Fri, Mar 01, 2013 at 11:00:52AM +0100, Vojtech Pavlik wrote:
>
> Mr. Blackhat then can load his i_own_your_ring0.ko module signed by his
> key on your system, having obtained root access previously.
The question will be what does Mr. Blackhat do with this
i_own_your_ring0.ko module. The FUD that has been flung about is that
it would be possible for Mr. Blackhat to create a small, tight
partition containing a signed Linux kernel (from Red Hat or SuSE,
doesn't reallly matter), and enough of a initrd which would include
said i_own_your_ring0.ko module. This would then be used in a bootkit
that would boot Linux and get ring0 access, and then use that to
create malware that would be used to infect Windows systems in a way
that wouldn't be detected by users.
It would essentially be the same as the bootsector virus, except it
would take 2 or 3 orders of magnitude more disk space, and probably
add one or two orders of magnitude more time to the boot time.
Whether this could be done in an undetectable fashion is an
interesting question, but the assertion is that it can be done, and so
we need to pour all sorts of unspeaking gunk into the kernel and
disable Systemtap to prevent this from happening.
> You call Microsoft, telling them what Mr. Blackhat has done.
>
> They now can:
>
> a) Do what you want: Disable Mr. Blackhat's account and revoke the hash
> of his binary.
>
> But also:
>
> b) Say, "oh well, we're sorry this kills your security model, but it's
> enough for us that you already fully booted Linux to worry about Windows
> security, this affects only your distribution and we don't care".
>
> c) Decide your security model is flawed, because you're abusing their
> signature process to mean something else from what they intended and
> revoke your shim hash instead.
Well, if this is being used to attack Windows machines (assuming that
it is possible to create a bootkit using a Linux kernel, and initrd,
and the signed i_pown_your_ring0.ko odule), it's unlikely that (b)
would be a likely outcome.
Both (a) and (c) would solve Microsoft's security problem. They could
do (c), but that would result in the PR and Legal morass resulting
from the accusatoin that they are abusing their monopoly position.
I'm not an expert in how much backbone the European anti-trust folks
have, so I can't really comment on how likely they would pursue this,
or whether they would be successful in the end, but more importantly,
I suspect Microsoft wouldn't be sure either.
- Ted