Hi Jason,
On Fri, Feb 10, 2012 at 10:08 AM, Jason Markley (ggsg) jamarkle@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