Mitch Bradley wrote:
> At some point, when these fairly obvious loopholes that we have known
> about since forever are closed, we plan to change the key so new
> machines will only run the more secure OS versions. Old machines will
> continue to be vulnerable until they are upgraded to new fi
At some point, when these fairly obvious loopholes that we have known
about since forever are closed, we plan to change the key so new
machines will only run the more secure OS versions. Old machines will
continue to be vulnerable until they are upgraded to new firmware with
the new key, and s
On Thu, 3 Jan 2008, John Richard Moser wrote:
> I did not address the mass of other crap you could do to the system with
> root. I was only addressing evading the OFW security implementation for
> only booting signed OSes.
Here's another vector:
1. On a laptop that comes from the factory with t
Bernardo Innocenti wrote:
> John Richard Moser wrote:
>
>> VECTOR 1: kexec()
>> [...]
>> VECTOR 2: unsigned module
>> [...]
>
> Unless we disable things such as /dev/mem, I also see a much
> wider attack vector, where one can inject arbitrary code in
> the kernel and recreate the conditions o
John Richard Moser wrote:
> VECTOR 1: kexec()
> [...]
> VECTOR 2: unsigned module
> [...]
Unless we disable things such as /dev/mem, I also see a much
wider attack vector, where one can inject arbitrary code in
the kernel and recreate the conditions of these. And there
are many alternative str
So far I have come up with two untested, theoretical ways to circumvent
the kernel signing mechanism and boot an unsigned kernel. These are
both dead simple so I'll keep the explanation short. Both require an
activation key, neither require a developer's key; in other words, if
you can boot n