Does U-boot support ASLR?
Curious if there is any built-in support for ASLR (address space layout randomization) in U-boot....does anybody know the level of support for such things?
-Jason
Dear Jason,
Quoted 3 lines · In message <[email protected]> you wrote:
Curious if there is any built-in support for ASLR (address space layout randomization) in U-boot....does anybody know the level of support for such things?
No it does not, and there are no plans to support such a thing.
Also, I think there was a presentation at one of the last Black Hat conferences that showed that address space randomization makes clracking systems _easier_. So I don't see any good reason even to think about adding such a thing.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Too many people are ready to carry the stool when the piano needs to be moved.
Quoted 6 lines · On Thursday 09 February 2012 10:13:29 Wolfgang Denk wrote:
Quoted 3 lines · Jason
Curious if there is any built-in support for ASLR (address space layout randomization) in U-boot....does anybody know the level of support for such things?
No it does not, and there are no plans to support such a thing.
i have a very hard time seeing how ASLR could possibly be useful to u-boot. we'd need to see some actual reasoning behind this proposal.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/5d4c268e/attachment.pgp>
A message that is not in the archive (sent off-list or not yet received): [email protected]
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
Quoted 7 lines
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/88b4b663/attachment.pgp>
Quoted 12 lines · Mike Frysinger
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
Quoted 7 lines
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?
Quoted 4 lines
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple
mwcommand. 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.
Quoted 3 lines
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.
Quoted 4 lines
- 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
Quoted 16 lines · On Thursday 09 February 2012 14:28:07 Scott Wood wrote:
Quoted 9 lines · Mike Frysinger
Quoted 7 lines · 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?
Quoted 5 lines
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple
mwcommand. 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.
Quoted 3 lines
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.
Quoted 8 lines
Quoted 5 lines
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts togenerate 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
Quoted 2 lines
It probably doesn't make sense as default behavior, but I could see it being useful in some situations.
such as ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/77da5576/attachment.pgp>
Quoted 15 lines · Mike Frysinger
Quoted 14 lines · On Thursday 09 February 2012 14:28:07 Scott Wood wrote:
Quoted 13 lines · Mike Frysinger
Quoted 7 lines · 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
mwcommand. 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.
Quoted 6 lines
Quoted 3 lines
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 0will 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
Quoted 21 lines
Quoted 8 lines
Quoted 6 lines
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts togenerate 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
Quoted 2 lines
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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Quoted 17 lines · Mike Frysinger
Quoted 16 lines · On Thursday 09 February 2012 14:28:07 Scott Wood wrote:
Quoted 14 lines · Mike Frysinger
Quoted 7 lines · 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
mwcommand. 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.
Quoted 7 lines
Quoted 3 lines
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 0will 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).
Quoted 10 lines
Quoted 8 lines
Quoted 5 lines
ignoring this, there are two fundamental issues with ASLR:
- this early on, u-boot has very little (if no) entropy, so any attempts togenerate 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.
Quoted 4 lines
Quoted 2 lines
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
Quoted 3 lines · 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.
Quoted 3 lines
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.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/8374d34f/attachment.pgp>
Quoted 6 lines · Mike Frysinger
Quoted 3 lines · 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?
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
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
Quoted 8 lines
-mike
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Quoted 12 lines · Scott Wood
Quoted 11 lines · Mike Frysinger
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
Quoted 7 lines
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?
Quoted 7 lines
Quoted 4 lines
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple
mwcommand. 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.
Quoted 6 lines
Quoted 4 lines
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 predictableThis 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.
Quoted 5 lines
Quoted 5 lines
- 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.
Quoted 8 lines
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
Quoted 2 lines · 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120209/2babebf8/attachment.pgp>
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
Quoted 9 lines · Graeme Russ
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?
Quoted 3 lines
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
Quoted 23 lines
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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Jason,
Quoted 12 lines · Jason Markley (ggsg)
Quoted 9 lines · Graeme Russ
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
Quoted 6 lines
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)
Quoted 5 lines
Quoted 2 lines
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,
Quoted 7 lines · In message <[email protected]> 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
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Nobody goes to that restaurant anymore. It's too crowded.
Quoted 12 lines · Scott Wood
Quoted 11 lines · Mike Frysinger
On Thursday 09 February 2012 13:37:15 Jason Markley wrote:
please don't top post, and keep the mailing list in cc
Quoted 7 lines
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?
Quoted 7 lines
Quoted 4 lines
u-boot is running in supervisor mode / ring 0 / etc... you have full access to the hardware with a simple
mwcommand. 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.
Quoted 6 lines
Quoted 4 lines
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 predictableThis 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.
Quoted 5 lines
Quoted 5 lines
- 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.
Quoted 8 lines
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Dear Jason,
please keep the ML on Cc:
Quoted 4 lines · In message <[email protected]> you wrote:
Do you happen to have a reference to that presentation? I'm very
interested, as i thought ASLR was in place to make it harder. I've done a weak google search but haven't turned up anything.
I'm sorry - I already searched when I wrote my first reply, but I didn't save the link when I read this. I am pretty much sure that it was in an article posted on http://www.heise.de/newsticker/ (and that it was in German language), but then it's likely that a similar article has been posted to http://www.h-online.com/ .
I can find a few articles that talk about ways to outsmart ASLR, for example
http://www.h-online.com/security/features/Return-of-the-sprayer-exploits-to-beat-DEP-and-ASLR-1171463.html
but none of the ones I checked contained the statement I quoted (that ASLR actually makes it easier for crackers), or I didn't find it.
Yes, the ideas behind ASLR was to make breaking into systems harder, and it does so for conventional attack methods. But breaking into systems is an art, and each new protection mechanism will attract forces to break them. In the end, you have to ask yourself if the efforts for a protection mechanism is worth the increaseof security it gives you.
As others have pointed out, U-Boot (while running in interactive mode) is pretty much open for unlimited access anyway, so what is there to protect?
And in production mode, U-Boot will just load and start some OS, and will be gone within a few milliseconds - if configured correctly, with little chances for break in.
Unless you attach a JTAG debugger - but then you are p0wned anyway.
Best regards,
Wolfgang Denk
Signature · 7 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
-- Edsger DijkstraQuoted 28 lines · Wolfgang Denk
Dear Jason,
please keep the ML on Cc:
Quoted 3 lines · In message <[email protected]> you wrote:
Do you happen to have a reference to that presentation? I'm very
interested, as i thought ASLR was in place to make it harder. I've done a weak google search but haven't turned up anything.I'm sorry - I already searched when I wrote my first reply, but I didn't save the link when I read this. I am pretty much sure that it was in an article posted on http://www.heise.de/newsticker/ (and that it was in German language), but then it's likely that a similar article has been posted to http://www.h-online.com/ .
I can find a few articles that talk about ways to outsmart ASLR, for example
http://www.h-online.com/security/features/Return-of-the-sprayer-exploits-to-beat-DEP-and-ASLR-1171463.html
but none of the ones I checked contained the statement I quoted (that ASLR actually makes it easier for crackers), or I didn't find it.Yes, the ideas behind ASLR was to make breaking into systems harder, and it does so for conventional attack methods. But breaking into systems is an art, and each new protection mechanism will attract forces to break them. In the end, you have to ask yourself if the efforts for a protection mechanism is worth the increaseof security it gives you.
Quoted 7 lines
As others have pointed out, U-Boot (while running in interactive mode) is pretty much open for unlimited access anyway, so what is there to protect?
And in production mode, U-Boot will just load and start some OS, and will be gone within a few milliseconds - if configured correctly, with little chances for break in.
Again, what about the U-boot API feature? I want to use the API feature, and have U-boot 'stick around' for more than 'a few milliseconds' as you put it. In production mode, when using the API feature, I think ASLR has some merrit
-Jason
Quoted 8 lines
Unless you attach a JTAG debugger - but then you are p0wned anyway.
Best regards,
Wolfgang Denk
Dear "Jason Markley (ggsg)",
Quoted 5 lines · In message <[email protected]> you wrote:
Again, what about the U-boot API feature? I want to use the API feature, and have U-boot 'stick around' for more than 'a few milliseconds' as you put it. In production mode, when using the API feature, I think ASLR has some merrit
Standalone programs are merely intended as a hook for people who have to run non-GPLed code. If all cases I know of this is low-level hardware test code as used in board bringup, for manufacturing tests, or in service.
If you find yourself using this in production you have made a number of design errors. When you want fancy features like security or such, then you should use software that was designed to provide such security, i. e. use a real OS.
Really. Just because it is possible to use something as a hammer does not mean it is a good idea to actually do this.
Best regards,
Wolfgang Denk
Signature · 5 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "How to make a million dollars: First, get a million dollars." - Steve Martin