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

[Daniel Dickinson]

Security is ultimately all about making it cost too much (of at least 
time, money, effort, requirements, social factors) to break in.  Even 
so-called 'real' security vs. security in depth and security by 
obscurity is really on the same spectrum.

That is why those who make bald statements about there being no point to 
security that isn't what they deem 'real' security, miss the reality 
that they're just talking about different points on the same spectrum.

Not that one should rely on *soley* on security by obscurity, but the 
reality is that even security by obscurity has it uses and can at least 
reduce attack surface.

For that matter the much vaunted example of DVD encryption shows that as 
much as weak security can be broken, it can achieve the ultimate 
objective well enough for long enough.  (In this case the objective is 
big media profits; dvd encryption prevented ordinary people from 
circumventing for long enough for them to make profit, therefore it 
actually succeeded at what it was designed for).

People tend to assume the objective of security is always absolute 'keep 
everyone out, even extremely well-funded antagonists', but that is not 
always actually the case.

Most of the time, the objectives are much more modest, and expecting 
people to prevent physical access to their home router or other devices 
running openwrt is rather unrealistic, but that doesn't mean we should 
leave it as trivial for someone to walk up to the device and gain 
passwordless root access.

It's all about managing the real risk of real situation using means that 
are not too onerous for benefit gained.

Like much of life, security is not nearly as black and white as many 
like to paint it (same with 'green' energy vs. fossil fuels; there is 
truly 'green' energy except not using energy, there are only degrees, 
and one needs to assess the full set impacts to really make an good 
decision about what's the right course of action).

Regards,

Daniel

On 24/12/15 04:51 PM, Sami Olmari wrote:
> -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 <mailto:bittorf at bluebottle.com>> wrote:
>
>     * Michael Richardson <mcr at sandelman.ca <mailto: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 <mailto:openwrt-devel at lists.openwrt.org>
>     https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
>
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel