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

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

[Jason Markley]

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

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

[Wolfgang Denk]

Dear Jason,

In message <4F33DC75.4040002@ggsg.cisco.com> 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

-- 
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.

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

[Mike Frysinger]

On Thursday 09 February 2012 10:13:29 Wolfgang Denk wrote:
> Jason 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.

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>

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

[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

> 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>

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

[Scott Wood]

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

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

[Mike Frysinger]

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
-------------- 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>

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

[Jason Markley]

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

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

[Jason Markley]

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

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

[Jason Markley]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

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

[Scott Wood]

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

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

[Mike Frysinger]

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>

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

[Mike Frysinger]

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
-------------- 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>

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

[Jason Markley]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

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

[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

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

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

[Jason Markley]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

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

[Graeme Russ]

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

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

[Wolfgang Denk]

Dear Jason,

please keep the ML on Cc:

In message <4F33E93E.5070804@ggsg.cisco.com> 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

-- 
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 Dijkstra

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

[Wolfgang Denk]

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

-- 
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.

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

[Jason Markley]

On 2/10/12 2:07 AM, Wolfgang Denk wrote:
> Dear Jason,
>
> please keep the ML on Cc:
>
> In message <4F33E93E.5070804@ggsg.cisco.com> 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.
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
>
> Unless you attach a JTAG debugger - but then you are p0wned anyway.
>
>
> Best regards,
>
> Wolfgang Denk
>

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

[Wolfgang Denk]

Dear "Jason Markley (ggsg)",

In message <4F351FDC.5010000@ggsg.cisco.com> 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

-- 
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