U-boot disable tftp with bootdelay=0 for GL-MT300N V2

Hi,

I would like to disable tftp in uboot so a client on the lan interface can't run a tftp server and force my device to boot a different image. One suggested way seems to be using bootdelay=0 in u-boot.

Is there a way to actually set bootdelay=0 from openwrt without rebuilding u-boot and without having a serial connection and manually entering u-boot? I found uboot-envtools but I can't figure out the correct fw_env.config for the GL-MT300N V2?
I tried different settings for fw_env.config...
I read: https://openwrt.org/docs/techref/bootloader/uboot.config#example_of_configuring_uboot-envtools

values I found for the MT300Nv2

root@4880c9f518be:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 0017e9a5 00010000 "kernel"
mtd5: 00e3165b 00010000 "rootfs"
mtd6: 00800000 00010000 "rootfs_data"

root@4880c9f518be:/# dmesg  | grep -i u-boot-env
[    0.369341] 0x000000030000-0x000000040000 : "u-boot-env"

from: https://github.com/gl-inet/uboot-source-for_mtk

./include/configs/rt2880.h


#define CFG_CONFIG_SIZE 0x10000

#define CFG_ENV_SECT_SIZE   CFG_CONFIG_SIZE
#define CFG_ENV_SIZE        0x1000

any hints very much appreciated!
thx 1000

First of all, I have no direct answer to your question.

But some thoughts.

OpenWrt itself is adding failsafe boot delay. So you would need to modify the image also. In addition to that some manufacturer providing recovery tools which do not relay on tftp or have dedicated rescue partitions or dualboot.

For getting a tftp image to the router you would need more than a tftp server. E. g. mostly pressing a specific button during power on cycle of the router. If someone has physical access to your router/lan and want to do nasty things he could try to tftp. But in case of this path is blocked (due to bootdelay=0) the attacker could try get the same device and replace yours also. :wink: Anyway ... In both cases the attacker has to know the configuration settings (due to config reset) to avoid complications in terms of e. g. a LAN downtime, no LAN access from clients (if leases only given out to specific MACs), login credentials for LuCI and/or dial up connection, etc. So you will notice that probably. On top of that the attacker need to powercycle the device, plugin the tftp device into the correct LAN port and the correct client config (IP Address) listening for tftp.

And to be honest ... If the attacker is acting from inside your LAN facility I would not relay on those (imo) "kittenish" things like blocking tftp on a router. It is probably easier to attack LuCI GUI directly for those destructive people. On top of that you will lose access to your device if a future upgrade is failing because you forgot to increase the value from 0 to 5 before upgrade.

If you really have advanced security needs you would need a set of security measures. E. g. MAC filtering, VLANs, 802.1X (Radius), etc.
If you need more use kerberos in connection with LAN encryption (IPSEC, WG).

If things are for private purposes only because your kids are trying to circumvent your security measures I would try simpler things like disassemble/block access to the reset button, power on/off button. A "hardware mod" makes imo much more sense in this case. Be creative like your kids. :smiley:

As there are many different options for different vendors I would like to try to keep this thread focused on the GL.iNet GL-MT300N V2 device (mt76x8).

https://openwrt.org/toh/gl.inet/gl.inet_gl-mt300n_v2

The problem I see is: Attacker gains access to a device on the lan side of the openwrt router. It then sets up a tftp server on 192.168.1.2 serving an image with openwrt-gl-mt300an.bin (see tcpdump output below) and waiting for the router to reboot. The router then sees 192.168.1.2 is up and asks for the filename openwrt-gl-mt300an.bin. If served it flashes the image to disk.
This hole process needs actually no phyisical access just a compromised device in the lan and some knowledge of openwrt. So I consider this a big problem and try to find a solution.

thanks for any more hints to disable this mechanism which is great for initial setup but rather dangerous for production systems.

boot sequence


Autobooting in: 2 s (type 'gl' to run U-Boot console)

Device have ART, checking calibration status...
Device have calibrated, checking test status...
Device haven tested, checking MAC info...
Device have MAC info, starting firmware...
host 192.168.1.2 is alive

Filename 'openwrt-gl-mt300an.bin'.
#################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##############################################
done
Bytes transferred = 6553842 (6400f2 hex)
NetBootFileXferSize= 006400f2
**************************
Erase start:0xbc050000
Erase len  :0x006500f2
Erase end  :0xbc6a00f2
**************************

this is taken on a host attached to the lan interface of the router to:

As a short remark - I just did set bootdelay=0 through serial but this still doesn't prevent booting from tftp as described above. Maybe I'm mixing up the tools/sequences involved. Would be great to get some insights from someone who knows what's really happening here. Thanks in advance!

Well I would assume that this is not the common behaviour of the routers at all and I agree this is an issue. But as I said already if an attacker is inside your LAN you have more serious problems. Remove untrusted clients and/or use a 2nd router to isolate those clients.

As I would try to avoid messing around with uboot/art/mtd partitions with an hexeditor (for a device I don't want to lose). I would try to find other/easier ways:

1st: Change your LAN-IP/DHCP Range to e. g. 10.0.0.0/24. Reboot and see if your device is still searching/accepting connections from a static client with the IP above.
2nd: Create a firewall rule and redirect this IP and/or block the IP. Port is 69 if I'm correct.
3rd: Use resolv.conf/hosts file or dnsmasq to redirect the IP.
4th: Use VLANS and/or Zones to seperate the LANs.
5th: Remove untrusted clients and/or use a 2nd router to isolate.

Gl.inet confirmed they setup this behaviour as default for business customers. Not sure if they ship their standard boxes like that. Other than that they stated that the behavior of blindly taking what is provided by 192.168.1.2 only happens if the wan interface is not connected. I did not verify this though since I already flashed my own u-boot to the device.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.