On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
ignoring this, there are two fundamental issues with ASLR: - this early on, u-boot has very little (if no) entropy, so any attempts to generate random numbers are going to be fairly predictable - scripts that u-boot runs at boot time often times need a chunk of memory to load and boot stuff out of. if u-boot could randomly be in the middle of that, then your board now randomly fails to boot. the only way around that would be to have u-boot do virtual addresses, and that's clearly a non-starter. -mike
On 02/09/2012 12:58 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
This assumes that the full command line interface is enabled, and is the mechanism of interaction in question. It doesn't apply to interactions over the network, special serial protocols, etc.
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts to
generate random numbers are going to be fairly predictable
This doesn't apply if there's a hardware random number generator -- and even poor entropy is more effort to guess than a fixed address.
- scripts that u-boot runs at boot time often times need a chunk of memory to
load and boot stuff out of. if u-boot could randomly be in the middle of that, then your board now randomly fails to boot. the only way around that would be to have u-boot do virtual addresses, and that's clearly a non-starter.
You'd just need to document which areas U-Boot could be in, and which areas are free for user use.
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
-Scott
On Thursday 09 February 2012 14:28:07 Scott Wood wrote:
On 02/09/2012 12:58 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
This assumes that the full command line interface is enabled, and is the mechanism of interaction in question. It doesn't apply to interactions over the network, special serial protocols, etc.
network/serial loads do no file length checks. `tftpload 0` will write until the server stops sending. not to mention there is no secure communication between u-boot and the server.
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts
to
generate random numbers are going to be fairly predictable
This doesn't apply if there's a hardware random number generator -- and even poor entropy is more effort to guess than a fixed address.
not when you know the starting point and can brute force it through
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
such as ? -mike
On 2/9/12 2:50 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 14:28:07 Scott Wood wrote:
On 02/09/2012 12:58 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
This assumes that the full command line interface is enabled, and is the mechanism of interaction in question. It doesn't apply to interactions over the network, special serial protocols, etc.
network/serial loads do no file length checks. `tftpload 0` will write until the server stops sending. not to mention there is no secure communication between u-boot and the server.
And having TFTP as an option in such a 'secure' boot loader would probably not make it past the checks necessary. So if it helps, assume that when someone is wanting to use ASLR, they also would configure U-boot to not have the tftpload command available.
-Jason
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts
to
generate random numbers are going to be fairly predictable
This doesn't apply if there's a hardware random number generator -- and even poor entropy is more effort to guess than a fixed address.
not when you know the starting point and can brute force it through
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
such as ? -mike
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 02/09/2012 01:50 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 14:28:07 Scott Wood wrote:
On 02/09/2012 12:58 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
This assumes that the full command line interface is enabled, and is the mechanism of interaction in question. It doesn't apply to interactions over the network, special serial protocols, etc.
network/serial loads do no file length checks. `tftpload 0` will write until the server stops sending. not to mention there is no secure communication between u-boot and the server.
Yes, there are insecure things you can do with the network interface -- if you're loading an image over TFTP and blindly booting that, obviously that's an attack vector.
But you could instead be doing cryptographic validation of the loaded image, or doing some sort of communication other than image loading.
As for tftpload not having length bounds, that's the kind of thing that anyone trying to put together a secure loader would want to fix (assuming they're using tftpload in the first place), but if such a hole gets through, perhaps ASLR might make it more difficult to use that length overrun to take control of the system (versus simply crash it).
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts
to
generate random numbers are going to be fairly predictable
This doesn't apply if there's a hardware random number generator -- and even poor entropy is more effort to guess than a fixed address.
not when you know the starting point and can brute force it through
I didn't say it was impenetrable, just more effort (depending on just how poor the entropy is).
I suspect most of the situations where you'd actually use this would involve a hardware random number generator, though, or some scheme to store entropy across reboots.
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
such as ?
When you can solve issues such as entropy generation, and are limiting external exposure to interfaces that should be secure (but might have bugs). I can especially see people wanting this who are using hardware secure boot mechanisms (i.e. U-Boot itself was cryptographically verified).
-Scott
On Thursday 09 February 2012 15:06:48 Scott Wood wrote:
As for tftpload not having length bounds, that's the kind of thing that anyone trying to put together a secure loader would want to fix (assuming they're using tftpload in the first place)
which is my point -- u-boot is so completely opening, throwing ASLR in there makes no sense. there are plenty of ways to break the system.
but if such a hole gets through, perhaps ASLR might make it more difficult to use that length overrun to take control of the system (versus simply crash it).
if you can overwrite any of u-boot, then i doubt this is that hard. this is what NOP slides are very good at.
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
such as ?
When you can solve issues such as entropy generation, and are limiting external exposure to interfaces that should be secure (but might have bugs). I can especially see people wanting this who are using hardware secure boot mechanisms (i.e. U-Boot itself was cryptographically verified).
this isn't an example of how ASLR would be useful -mike
On 2/9/12 3:34 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 15:06:48 Scott Wood wrote:
As for tftpload not having length bounds, that's the kind of thing that anyone trying to put together a secure loader would want to fix (assuming they're using tftpload in the first place)
which is my point -- u-boot is so completely opening, throwing ASLR in there makes no sense. there are plenty of ways to break the system.
There are plenty of ways to break any system. Isn't the whole idea of security that you simply make it harder for particular attack vectors to be fruitful? You're not going to be able to prevent EVERY attack, so should we just not bother with security at all?
but if such a hole gets through, perhaps ASLR might make it more difficult to use that length overrun to take control of the system (versus simply crash it).
if you can overwrite any of u-boot, then i doubt this is that hard. this is what NOP slides are very good at.
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
such as ?
When you can solve issues such as entropy generation, and are limiting external exposure to interfaces that should be secure (but might have bugs). I can especially see people wanting this who are using hardware secure boot mechanisms (i.e. U-Boot itself was cryptographically verified).
this isn't an example of how ASLR would be useful
Isn't ASLR useful in the sense that it does what ASLR was created to do? make it 'harder' (not impossible, but another layer of difficulty) for attacking code to determine where particular code lives?
Are you arguing that ASLR isn't useful for anything at all? Or just useful for U-boot? If anything at all, why is it implemented in so many other places? If just U-boot, isn't plugging one small hole, even though larger holes exist still making progress?
-Jason
-mike
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 2/9/12 2:28 PM, Scott Wood wrote:
On 02/09/2012 12:58 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
This assumes that the full command line interface is enabled, and is the mechanism of interaction in question. It doesn't apply to interactions over the network, special serial protocols, etc.
Agree with Scott. A board that wanted to use ASLR for U-boot would probably also want to restrict the cmd set available to the user.
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts to
generate random numbers are going to be fairly predictable
This doesn't apply if there's a hardware random number generator -- and even poor entropy is more effort to guess than a fixed address.
Totally agree.
- scripts that u-boot runs at boot time often times need a chunk of memory to
load and boot stuff out of. if u-boot could randomly be in the middle of that, then your board now randomly fails to boot. the only way around that would be to have u-boot do virtual addresses, and that's clearly a non-starter.
You'd just need to document which areas U-Boot could be in, and which areas are free for user use.
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
-Scott
Exactly. There would be a range of memory that U-boot could be in, but you would still be able to have a large chunk of space for scripts to load and boot from. Depending on how much memory a particular board has, the 'chunk' required could be small in comparison to the available memory. Agree, that if the board has little to no 'available' memory to randomize because it needs all it's available memory for loading an OS, that ASLR on such a platform doesn't make sense, but who's to say it wouldn't be useful for other boards?
-Jason
On Thursday 09 February 2012 14:55:09 Jason Markley wrote:
that ASLR on such a platform doesn't make sense, but who's to say it wouldn't be useful for other boards?
you have yet to show how it'd be useful. as the person proposing the new feature, it's on you to show why it isn't just a waste of time. -mike
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
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)
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
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
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
Dear Jason,
In message 4F3451DE.3050503@ggsg.cisco.com you wrote:
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?
Well, we always have to ask ourself what the benefit of any patch is: Is it useful to soemone? Does it hurt others? Does it improve U-Boot in any significant way? Does it make maintainance of U-Boot easier or more difficult? etc.
In case of ASLR, my personal feeling is that there are tons and tons of other areas that would be way more important to "harden" U-Boot.
Adding ASLR sounds to me just like a buzzword you can put on some list of features, where it does not help you anything except maybe to collect some brownie points.
Best regards,
Wolfgang Denk
On 2/9/12 2:28 PM, Scott Wood wrote:
On 02/09/2012 12:58 PM, Mike Frysinger wrote:
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
I agree any proposal would need to be accompanied by good reasoning. I'm honestly a little confused as to why a generally accepted security feature such as ASLR would NOT be useful for u-boot. U-boot has the capability to interact with the outside world via the network as well as the console. When using the U-boot API, it also remains resident in memory. Wouldn't something like ASLR enhance the security posture of U-boot in those situations?
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple `mw` command. randomizing the address base of u-boot doesn't gain you anything. so no, i see no advantage of u-boot itself utilizing ASLR regardless of what it interacts with.
This assumes that the full command line interface is enabled, and is the mechanism of interaction in question. It doesn't apply to interactions over the network, special serial protocols, etc.
Agree with Scott. A board that wanted to use ASLR for U-boot would probably also want to restrict the cmd set available to the user.
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts to
generate random numbers are going to be fairly predictable
This doesn't apply if there's a hardware random number generator -- and even poor entropy is more effort to guess than a fixed address.
Totally agree.
- scripts that u-boot runs at boot time often times need a chunk of memory to
load and boot stuff out of. if u-boot could randomly be in the middle of that, then your board now randomly fails to boot. the only way around that would be to have u-boot do virtual addresses, and that's clearly a non-starter.
You'd just need to document which areas U-Boot could be in, and which areas are free for user use.
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
-Scott
Exactly. There would be a range of memory that U-boot could be in, but you would still be able to have a large chunk of space for scripts to load and boot from. Depending on how much memory a particular board has, the 'chunk' required could be small in comparison to the available memory. Agree, that if the board has little to no 'available' memory to randomize because it needs all it's available memory for loading an OS, that ASLR on such a platform doesn't make sense, but who's to say it wouldn't be useful for other boards?
-Jason
participants (6)
-
Graeme Russ -
Jason Markley -
Jason Markley (ggsg) -
Mike Frysinger -
Scott Wood -
Wolfgang Denk