[OpenWrt-Devel] [PATCH] base-files utils/busybox: Make requiring login in console default for easily accessed devices

[Sami Olmari]

-1 to default key...

> at the moment the user *is* used to a key mismatch, because
> every box comes up with 192.168.1.1 and another key.

No need to generate another weak point just because there can be another
similar one...

More general, should a bad guy have physical access to an device, be it
embedded router or full server, the game is mostly lost at that point
already... He can allways take out the hard disk and boot own linux and
read the contents etc...

I could see the point of serial connection asking password in normal boot,
but no point with that in failsafe... for same reasons than above... mr bad
guy can even flash own bootloader to do stuff should he need access to
embedded device contents...

So, to recap, bad guy + physical access = game over, no matter what you try
to do...

 mine .02, Sami Olmari

On Thu, Dec 24, 2015 at 11:33 PM, Bastian Bittorf <bittorf at bluebottle.com>
wrote:

> * Michael Richardson <mcr at sandelman.ca> [24.12.2015 22:14]:
> >     >> > till the real keys are generated? it can last several minutes
> on some
> >     >> > routers and it feels like the box is broken. also: if really
> something
> >     >> > goes wrong during key generating we can at least login.
> >     >>
> >     >> you have a very bizarre understanding of securing a device.
> >
> >     > in this stage the box is still without password.
> >
> > okay.  So the impersonator machine lets the user in without a password,
> and
> > the impersonator machine has ALREADY connected to the new machine with no
> > password, and trojan'ed some binaries.
>
> yes, if somebody wants to upload some binaries it's possible.
>
> >     > the only issue i can think of is, that one can
> >     > read on the wire to which password somebody changes
> >     > with 'passwd' - but i'am pretty sure this is not
> >     > the case, because each session has it's own privacy.
> >
> > No, since the impersonator (MITM) has involved itself with the session.
> > Effectively, the MITM creates:
> >
> >              ssh mitm 'tee /badguy | ssh target'
> >
> > (but, bidirectionally, and inside the SSH transport layer)
> >
> > A new ICMP port-unreachable code would be nice to have here.
>
> interesting idea, but this is also possible with the current
> approach. the user has to accept a new unknown key and has no
> idea from which box it comes from.
>
> but really, this is really hypothetical - normally you have
> 1 box on your desk and you are connected via wire to it. what
> is your usecase?
>
> bye, bastian
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20151224/1b1c119a/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel