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?
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?
-Jason
Network: Hit it with IP packets - But U-Boot only activates network code on as as-needed basis (typically when someone runs a net command like tftp etc) so you already have U-Boot shell access anyway
Serial: Buffer overruns on commands - U-Boot will crash and the board reboots and again, you probably already had/have shell access
So it starts to boil down to protecting access to the shell - Access to the shell opens up all sorts of possibilities such as changing environment variables (including scripts) up to completely replacing the U-Boot image
So my thought would be, if you want to improve U-Boot security, perhaps implement password protection on the shell
Regards,
Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot