Hacker News Reader

Comment by somepig | Hacker News Reader

Oh the Espressobin. The poor thing has a dozen or so variants, and each one requires a different u-boot image. Fortunately they ship with the u-boot image on SPI flash, so in theory you could just let it be and not worry about the variants... except for the massive security issue where the stock u-boot bridges all ethernet ports.

With a stock u-boot, from the time the bootloader brings up the ethernet switch until Linux takes over it with dsa and bridge-utils, your LAN ports are directly bridged with your WAN port.

View on HN

I gave up using mine as a firewall and just run pihole + samba w/ a couple of drives on it.

I tried to rebuild u-boot from source w/o the network boot code since the latest Linux Kernel has drivers for the Topaz switch now, but no matter what I tried I couldn't get it to boot.

The documentation leaves a lot to be desired....

I’m really curious, as someone with little knowledge of these kinds of security considerations, why is it bad to have the wan port and the lan ports bridges?

wan = outside firewall

lan = inside firewall

You don't want to bridge them because then it just bypasses the firewall.

That's not true.

LAN traffic is still going through the router, where the firewall supposedly runs.

Regardless of other devices having a public IP, if the router blocks forwarding packets (which is one of the main functionalities of a firewall), then the device(s) behind it are just as protected as if they had private IPs.

It's just a bit easier to setup forwarding as it doesn't require NAT, and it's also easier to open up by accident but having a public IP does not bypass the firewall.

Depends, a typical use case of this device would be a router, or a firewall, so the point GP makes is very much valid.

the entire reason the devices get public a public IP is because the firewall effectively isn't there. from the time u-boot inits the topaz chip, until linux controls the chip, it behaves like a dumb ethernet switch.

some ISPs will happily assign public IPs to any hardware address that sends a DHCP request. This means while the network segments are bridged, all local devices are potentially obtaining public IP addresses and are exposed to the internet at large.

This is problematic if you have home network devices with vulnerabilities or services running on hosts with the assumption that the host will only ever be on a private network (unauthenticated file servers, etc)

There is also an issue with the number of devices exposed to the ISP -- many will issue an address to the first device they see on a link, then ignore all other devices until the lease expires or is released. That means your PS4 may get a lease before the espressobin's Linux takes over, and the ISP will ignore the subsequent dhcp request from the espressobin.

I still prefer having the bootloader in SPI - worst case I can just chain load another newer / custom u-boot from TFTP or SD card.

At the moment I've got an unbootable Rockchip RK3399 board on my desk because at some point the bootloader image format has changed and rkdeveloptool refuses to let me boot from or flash the image to the device.

Do you know of any patches that keep the NIC turned off until Linux is ready?

If I knew of any such patches, I couldn't share them for Reasons, but suggest poking around mv88e6xxx_initialize in u-boot.

https://github.com/MarvellEmbeddedProcessors/u-boot-marvell/...

That's the init code for the network chip. I tried removing it, the code compiles, but the board won't boot w/ it(I imagine due to something unrelated).

Reply on news.ycombinator.com