[U-Boot] Does U-boot support ASLR?

[Graeme Russ]

Hi Jason,

On Fri, Feb 10, 2012 at 10:08 AM, Jason Markley (ggsg)
<jamarkle at ggsg.cisco.com> wrote:
>
>
> On 2/9/12 5:16 PM, Graeme Russ wrote:
>> Hi Guys,
>>
>> My 2c worth...
>>
>> The thought of applying ASLR to improve security is pointless unless you
>> have identified a reason to do so. You can't just apply a security
>> hardening technique willy-nilly and expect you security to improve. The
>> security of a system is equal to the weakest link and no amount of
>> strengthening the other links will improve security
> Agreed, but in the grand scheme of things, does that mean the
> maintainers of U-boot will ONLY allow patches in that fix the biggest
> security hole that currently exists?  If someone desires to patch a
> small hole because they have a reason to, or desire to, but it's
> currently the biggest hole out there, should said person be denied the
> opportunity to present a patch for the hole they've identified?

Of course not, but ASLR would introduce a complexity that is not in
proportion to the problem being solved.

No-one is ever prevented from presenting a patch - You are more than
welcome to write it and post it to the list. Have a look through the
archives, plenty of patches have been presented that have been regected
(mine included)

>> Remember, U-Boot is a boot-loader. It is very transitory. Think about how
>> an attacker could exploit U-Boot (Hint: 10s after booting, they can't)
> What about the U-boot API infrastructure?  Isn't that designed to allow
> a program that U-boot loads to call back into U-boot to perform some
> function?  Doesn't that mean U-boot is no longer transitory?

Don't mistake U-Boot having a stand-alone API as being the same as U-Boot
being an OS. In theory you could write a malicious stand-alone application,
store it on an SD card, load it up and run it but you have console access,
so you are already well past any effective security ASLR or NX etc would
provide anyway.

U-Boot is a boot loader - It initialises enough hardware to get the OS
loaded and running and thats it. As I understand it, the API is there
primarily for extended test suites designed to test hardware during
manufacturing.

And U-Boot is a single user environment - You don't need to exploit it in
order to get 'root' access - If you have command line, you have root. If
you really wanted to harden U-Boot against a malicous user, I would look
at providing protected access to the shell first.

So I think you need to have a good think about what ASLR is designed to
mitigate (privilege escalation due to buffer overrun and arbitrary code
execution) and think of how it applies to U-Boot (which it does not as
there is not multiple privilege levels to escalate between)

Regards,

Graeme