espressobin uboot security concerns switch init portmask

[FoodGenius]

can somebody confirm this problem?
 

in the year 2017 someone mentioned in http://espressobin.net/forums/topic/boot-behavior-of-the-switch-and-security/

some security concerns with older uboot bootloaders and port-mask setting in armada-3720-espressobin.dts(i)

 

this seems still to be the case in the current released armbian bootloaders  found in https://dl.armbian.com/espressobin/u-boot/

 

WTMI-devel-18.12.1-e6bb176
U-Boot 2018.03-devel-18.12.3-gc9aa92c-armbian (Feb 20 2019 - 09:45:04 +0100)

 

since they also seem to use  port-mask = <0xf> instead of the suggested port-mask = <0x3> ?!

 

https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/blob/u-boot-2018.03-armada-18.12/arch/arm/dts/armada-3720-espressobin.dts#L55

 

this means...

 

as soon as ESPRESSOBin board (revision v5 and v7) gets powered up,  you will see that u-boot is still initialising the switch chipset to forward traffic.

u-boot sets the topaz switch chipsatz portmask in a way that the board is in "full switch mode" and  all ports are bridged.

 

security concers:

* at every "normal" reboot you have bridged the ports for some seconds, until armbian final loads the linux kernel, newer dtb and module mv88e6xxx.
* but furthermore... if you stop autoboot manually, or if your boot fails for any reason (boot-medium has a corrupt filesystem).. you will run into the serious problem,
that you're stuck in the Marvell Uboot Console, which is default forwarding all traffic... and so you LAN and WAN ports are bridged all the time. 

 

the switch chipset seems to have bootstrap pins which allows at least 3 different configurations:
1. start with forwarding enabled
2. start with forwarding disabled
3. fetch configuration from EEPROM

as mentioned in espressobin forum, the RGE_RXD3 has a pull down and tis should prevent traffic flow at reset/power up by default..
.... but u-boot is (re)enabling the forward again.

 

So it seems, that all uboot images for espressobin should have the setting with disabled lan ports and just use wan port per default.

how to fix?
 

 

Edited January 7, 2020 by FoodGenius
added links

[FoodGenius]

as a quick and dirty workaround... without rebuilding the bootloader images....  i fiddle with uboot "switch" command

 

switch phy_write 1 0 0 0xffff

 

to disable the ports at boot, just by prepending to bootcmd variable. so even if there is no microsd card available or filesystem or kernel image is corrupt, the ports gets deactivated and no traffic ist forwarded.
so you can use

 

setenv bootcmd 'switch phy_write 1 0 0 0xffff;for target in ${boot_targets}; do run bootcmd_${target}; done'

 

but the "2 seconds timeout prompt" is still there, so you have a small window of 2-3 seconds at boot time, where lan/wan still gets forwarded/bridged.... and if uboot itself hangs (memory timing or instability of powersource ).. there is still the problem of forwarding traffic until manually triggered hard reset or shutdown.

 

also if you enter the uboot console, switch forwarding is still active. so your first command in console should be.
 

switch phy_write 1 0 0 0xffff

if you dont won't to set wan port down, use 2 or 3 for the lan0 and lan1.

switch phy_write 1 0 0 0xffff -> WAN
switch phy_write 2 0 0 0xffff -> LAN0
switch phy_write 3 0 0 0xffff -> LAN1

 

Update: @Igor perhaps you want to mention this alternative bootcmd var at the current armbian infopage?

https://www.armbian.com/espressobin/

[Pali]

Hello @FoodGenius!

 

Proper fix for this issue will be part of U-Boot version v2020.10-rc4.

 

But instead of doing hack/workaround by completely disabling all lan ports, fix in U-Boot v2020.10 just disables forwarding packets between lan and wan interfaces.

 

So packets from non-CPU ports would not be forwarded to other non-CPU ports (fixes this security issue) and packets from CPU port would be still forwarded to all other ports like before (so netboot will work as before via any port, unlike your workaround).

 

Plus configuration is set prior enabling Topaz forwarding, so there is no time window in which insecure configuration is active.