After updating from 2.0.7 to 2.4.0, we’re finding that dns is failing on specific routers, plume B1A routers is at least one we find that fails. Any ideas where to start?
Is there a way to feed wireshark data in to the engine on a pc? Everything looks fine on the wireshark (Pulled from device interface), but the stack isn’t liking something here.
I’ve attached DNS filtered packets.
DNS_issue.zip (4.2 KB)
I think I’ve found the issue, ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS defaults to 0
I don’t really agree with this, defaults that have the ability to break connections shouldn’t be 0 like this. Every other device we’ve used on this network connects, which tells me most stacks default to not checking the checksum. So if its going to default to checking, and especially since previous versions of the stack act differently, it seems like this should default to 1, or else error out in the preprocessor.
Thanks for reporting this.
In the old days, a UDP checksum of zero would be accepted by any host… until this feature was misused by malicious attackers. That is the reason why we decided to define the default:
#define ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS 0
I understand that this may cause a problem when upgrading: as in your case, UDP doesn’t work anymore.
I’m sorry for the inconvenience, but we believe that security was more important than downward compatibility.
In fact I’ve rarely seen devices that set the UDP checksum to zero. I used to make it zero because it was a faster option.
Yes, but the issue here isn’t that UDP doesn’t work, its that DNS doesn’t work, which I can’t control, and the customers don’t care why.
Perhaps +TCP needs to at least allow some type of option for DNS? Otherwise what are good options, try to get a router company to fix their software? Problem is we have one ISP that uses these routers now for new installs.
Hi @friesen,
Yes, so you can define ipconfigUDP_PASS_ZERO_CHECKSUM_PACKETS=1 and it will work again. Or am I missing something?
Well, its global to all UDP then, I wonder if this should rather be a sock opt that defaults to 0, but I don’t know what type of malicious attack surface FreeRTOS was trying to close.
I have seen reports about UDP attacks that abuse the feature that CRC=0 will always be accepted.
I admire the people who investigate and report this. The purpose of the attackers is to take over control of your CPU.
Image that the attacker is able to change the length field of an incoming packet, without causing a CRC error. And suppose that the packet will overwrite some essential piece of memory?
So when you make an exception for DNS, attacks might still be possible.
Yes, we could make an exception with a socket option.
There is already a socket option FREERTOS_SO_UDPCKSUM_OUT, which allows to send UDP packets with CRC=0.
So yes, we can add a new socket option FREERTOS_SO_UDPCKSUM_IN.
It’ll require a bit of code and configuration to have DNS set this option.