[U-Boot] Disable command at runtime

[U-Boot] Disable command at runtime

[kubiznak.petr]

Hello,

I wonder whether it is possible to dynamically enable/disable a command. 
Since u-boot does not provide any secure authentication method, it is 
dangerous to keep some commands available to a potential hacker. E.g. 
the "fuse" command. On the other hand, I need these commands during the 
manufacturing process. So my idea is to enable/disable the commands 
dynamically based on some obscure logic. Is there a way to do it without 
need to deeply hack the code?

Thanks,

Petr





--
View this message in context: http://u-boot.10912.n7.nabble.com/Disable-command-at-runtime-tp262632.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Disable command at runtime

[Tom Rini]

On Thu, Jul 28, 2016 at 04:40:29AM -0700, kubiznak.petr wrote:

> Hello,
> 
> I wonder whether it is possible to dynamically enable/disable a command. 
> Since u-boot does not provide any secure authentication method, it is 
> dangerous to keep some commands available to a potential hacker. E.g. 
> the "fuse" command. On the other hand, I need these commands during the 
> manufacturing process. So my idea is to enable/disable the commands 
> dynamically based on some obscure logic. Is there a way to do it without 
> need to deeply hack the code?

Well, there's a few ways to do this.  The first way would simply be to
install a different build of U-Boot onto the board than the one used
during flashing as part of the manufacturing process.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160729/5fe0dbdb/attachment.sig>

[U-Boot] Disable command at runtime

[Petr Kubizňák]

Hi Tom, thanks for your reply.

Such way is of course possible, but you surely know I'm rather 
interested in more clever solutions. Besides the understandable fact 
that I don't want to maintain two u-boot variants and flash it twice, I 
also believe it can be useful to lock "almost everything" and unlock it 
once I need, e.g. in case of some troubles.

So any suggestions which would really answer my question, please?


On 07/29/2016 03:31 PM, Tom Rini wrote:
> On Thu, Jul 28, 2016 at 04:40:29AM -0700, kubiznak.petr wrote:
>
>> Hello,
>>
>> I wonder whether it is possible to dynamically enable/disable a command.
>> Since u-boot does not provide any secure authentication method, it is
>> dangerous to keep some commands available to a potential hacker. E.g.
>> the "fuse" command. On the other hand, I need these commands during the
>> manufacturing process. So my idea is to enable/disable the commands
>> dynamically based on some obscure logic. Is there a way to do it without
>> need to deeply hack the code?
> Well, there's a few ways to do this.  The first way would simply be to
> install a different build of U-Boot onto the board than the one used
> during flashing as part of the manufacturing process.
>

[U-Boot] Disable command at runtime

[Tom Rini]

On Fri, Jul 29, 2016 at 04:37:31PM +0200, Petr Kubiz??k wrote:

> Hi Tom, thanks for your reply.
> 
> Such way is of course possible, but you surely know I'm rather
> interested in more clever solutions. Besides the understandable fact
> that I don't want to maintain two u-boot variants and flash it
> twice, I also believe it can be useful to lock "almost everything"
> and unlock it once I need, e.g. in case of some troubles.
> 
> So any suggestions which would really answer my question, please?

It wouldn't be two variants, but two defconfigs.  But, no, we do support
locking things down such that we only boot verified images.  We don't
have any sort of lock/unlock or disable/enable of certain commands at
the prompt.  You would be better served by having an emergency
self-contained kernel + ramdisk to deal with troubles rather than being
in U-Boot, most likely.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160729/c88e2639/attachment.sig>

[U-Boot] Disable command at runtime

[Petr Kubizňák]

Ok, I get it, then I'll have to deal with two defconfigs and reflashing 
for now.

Anyway, at least a user feedback / feature request... I believe it would 
be useful for many users to have a manufacturing mode, which they would 
escape permanently by e.g. executing some command. In normal mode, some 
commands would be disabled. Logic would be similar to 
CONFIG_OVERWRITE_ETHADDR_ONCE.


On 07/29/2016 04:59 PM, Tom Rini wrote:
> On Fri, Jul 29, 2016 at 04:37:31PM +0200, Petr Kubiz??k wrote:
>
>> Hi Tom, thanks for your reply.
>>
>> Such way is of course possible, but you surely know I'm rather
>> interested in more clever solutions. Besides the understandable fact
>> that I don't want to maintain two u-boot variants and flash it
>> twice, I also believe it can be useful to lock "almost everything"
>> and unlock it once I need, e.g. in case of some troubles.
>>
>> So any suggestions which would really answer my question, please?
> It wouldn't be two variants, but two defconfigs.  But, no, we do support
> locking things down such that we only boot verified images.  We don't
> have any sort of lock/unlock or disable/enable of certain commands at
> the prompt.  You would be better served by having an emergency
> self-contained kernel + ramdisk to deal with troubles rather than being
> in U-Boot, most likely.
>

[U-Boot] Disable command at runtime

[Wolfgang Denk]

Dear Petr,

In message <9c257c71-97b6-a83e-3d9d-e3a8459fc080@elnico.cz> you wrote:
> 
> Anyway, at least a user feedback / feature request... I believe it would 
> be useful for many users to have a manufacturing mode, which they would 
> escape permanently by e.g. executing some command. In normal mode, some 
> commands would be disabled. Logic would be similar to 
> CONFIG_OVERWRITE_ETHADDR_ONCE.

How could that ever be "safe" - in the sense of protecting against an
attacker?  How could you perform such a "switch" between modes?  By
setting some bit somewhere.  And it has to be in some persistent
storage.  And the source code of your image is available to the
public.  What should prevent an attacker from undoing your bit
setting and switching back to "full" mode?

U-Boot is a boot loader, not a high security environment.  If you
grand somebody access to the U-Boot command line interface, he owns
the system.  If not directly, so by just pulling a few simple tricks.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
If it went on at this rate, in several billion  years  he'd  be  rich
beyond his wildest dreams!            - Terry Pratchett, _Soul Music_

[U-Boot] Disable command at runtime

[Petr Kubizňák]

Dear Wolfgang,

On 08/01/2016 10:05 PM, Wolfgang Denk wrote:
> How could that ever be "safe" - in the sense of protecting against an
> attacker?  How could you perform such a "switch" between modes?  By
> setting some bit somewhere.  And it has to be in some persistent
> storage.  And the source code of your image is available to the
> public.  What should prevent an attacker from undoing your bit
> setting and switching back to "full" mode?
If it was to be an irreversible switch, a reliable way might be to 
effectively remove some parts of the program by overwriting them. Not 
that I ever have done that, perhaps it's not that easy as I imagine, but 
I believe it's possible.
> U-Boot is a boot loader, not a high security environment.  If you
> grand somebody access to the U-Boot command line interface, he owns
> the system.  If not directly, so by just pulling a few simple tricks.
You are absolutely right, whoever has access to U-Boot, can easily 
destroy the system. The main problem is perhaps in my understanding of 
the concept. I'm always tempted to keep access to U-Boot "for future 
sakes", but have not found a reliable way to deny the access to the 
others. Is there a "correct approach"?

By the way, once I read in some conversation that bad security is no 
security, so that's why U-Boot does not implement bad security. From my 
point of view, bad security (e.g. password stored in env) is strong 
enough to keep away the amateurs who just want to play with it and don't 
really know they might destroy the system. Of course it does not secure 
the system from the really evil attackers, but what does?

Best Regards,
Petr

[U-Boot] Disable command at runtime

[Wolfgang Denk]

Dear Petr,

In message <201343a2-69c2-6c3e-442b-a228190a8d07@elnico.cz> you wrote:
> 
> > attacker?  How could you perform such a "switch" between modes?  By
> > setting some bit somewhere.  And it has to be in some persistent
> > storage.  And the source code of your image is available to the
> > public.  What should prevent an attacker from undoing your bit
> > setting and switching back to "full" mode?
> If it was to be an irreversible switch, a reliable way might be to 
> effectively remove some parts of the program by overwriting them. Not 
> that I ever have done that, perhaps it's not that easy as I imagine, but 
> I believe it's possible.

If you are able to overwrite the code, what would an attacker prevent
from doing the same?  Note that an in-memory modification (life patch)
is sufficient.

> You are absolutely right, whoever has access to U-Boot, can easily 
> destroy the system. The main problem is perhaps in my understanding of 

Not only destroy,  He can take control.

> the concept. I'm always tempted to keep access to U-Boot "for future 
> sakes", but have not found a reliable way to deny the access to the 
> others. Is there a "correct approach"?

If security is an issue, then you should 1) use signed images (with
sufficient hardware support), and 2) prevent the execution of
user-defined, unchecked commands (disable the CLI).

> By the way, once I read in some conversation that bad security is no 
> security, so that's why U-Boot does not implement bad security. From my 
> point of view, bad security (e.g. password stored in env) is strong 
> enough to keep away the amateurs who just want to play with it and don't 
> really know they might destroy the system. Of course it does not secure 
> the system from the really evil attackers, but what does?

As the very first step, you have to define which security level you
need.  Only then you can access which risks are acceptable and which
not.  In general it is a good approach to consider an open CLI
interface in U-Boot as a mighty tool for all kinds of use.

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

Same holds for U-Boot...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
Never ascribe to malice that which can  adequately  be  explained  by
stupidity.

[U-Boot] Disable command at runtime

[Ladislav Michl]

On Fri, Jul 29, 2016 at 05:57:58PM +0200, Petr Kubiz???k wrote:
> Ok, I get it, then I'll have to deal with two defconfigs and reflashing for
> now.
> 
> Anyway, at least a user feedback / feature request... I believe it would be
> useful for many users to have a manufacturing mode, which they would escape
> permanently by e.g. executing some command. In normal mode, some commands
> would be disabled. Logic would be similar to CONFIG_OVERWRITE_ETHADDR_ONCE.

You can still download U-Boot standalone application implementing whatever
you need to do in production, so in "normal mode" your manufacturing secrets
are not even part of your product.

Best regards,
	ladis

[U-Boot] Disable command at runtime

[Petr Kubizňák]

Dear ladis,

Thanks for your comment, I didn't really know about the standalone 
applications mechanism, it might surely be useful.

Best Regards,
Petr


On 08/01/2016 10:38 PM, Ladislav Michl wrote:
> You can still download U-Boot standalone application implementing whatever
> you need to do in production, so in "normal mode" your manufacturing secrets
> are not even part of your product.
>
> Best regards,
> 	ladis

[U-Boot] Disable command at runtime

[Simon Glass]

Hi,

On 29 July 2016 at 07:31, Tom Rini <trini@konsulko.com> wrote:
> On Thu, Jul 28, 2016 at 04:40:29AM -0700, kubiznak.petr wrote:
>
>> Hello,
>>
>> I wonder whether it is possible to dynamically enable/disable a command.
>> Since u-boot does not provide any secure authentication method, it is
>> dangerous to keep some commands available to a potential hacker. E.g.
>> the "fuse" command. On the other hand, I need these commands during the
>> manufacturing process. So my idea is to enable/disable the commands
>> dynamically based on some obscure logic. Is there a way to do it without
>> need to deeply hack the code?
>
> Well, there's a few ways to do this.  The first way would simply be to
> install a different build of U-Boot onto the board than the one used
> during flashing as part of the manufacturing process.

Also see cli_process_fdt() which allows you to lock out commands using
a device-tree setting. This avoids changing the U-Boot binary - it is
easy enough to update the device tree using fdtput. This is how Chrome
OS did it.

Regards,
Simon

[U-Boot] Disable command at runtime

[Petr Kubizňák]

Hi Simon,

> Also see cli_process_fdt() which allows you to lock out commands using
> a device-tree setting. This avoids changing the U-Boot binary - it is
> easy enough to update the device tree using fdtput. This is how Chrome
> OS did it.
Hmm, interesting approach. Thanks for your suggestion.

Petr

[U-Boot] Disable command at runtime

[Wolfgang Denk]

Dear Petr,

In message <1f085e1d-378c-5f29-2f35-988b8d110da8@elnico.cz> you wrote:
> 
> I wonder whether it is possible to dynamically enable/disable a command. 
> Since u-boot does not provide any secure authentication method, it is 
> dangerous to keep some commands available to a potential hacker. E.g. 

If some evil guy has access to the U-Boot command line interface you
are pawned anyway.

> the "fuse" command. On the other hand, I need these commands during the 
> manufacturing process. So my idea is to enable/disable the commands 
> dynamically based on some obscure logic. Is there a way to do it without 
> need to deeply hack the code?

You have to modify the code to implement such a thing; but it should
not require any "deep hacking".  But then, I doubt it's useful.  If
you let an attacker run _any_ commands on your system you are already
doomed.  If it's in U-Boot, you lost.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
Of course there's no reason for it, it's just our policy.