Hi,

Thank you for bringing it to the notice here on the mailing list. We have been working on a possible patch for the same, the beta version of the patch is available here on the mailing list.

Wrt the specific router you have mentioned, I dont know the details, maybe someone else with knowledge of that particular router and its firmware(s) will provide you the answer.

What I can say in general at a high level is that just because a networking related application in a embedded device or on the router is compiled against uclibc, doesnt make it automatically vulnerable. If there is a local dns caching/resolver daemon setup, then the dns query generated by the application/uclibc will go to this local logic. It inturn will decide whether to serve the info it already caches and or make a new request. In turn how this local dns caching/resolver daemon handles the dns query for further processing is what will decide, whether there is a risk with dns poison or not.

However devices which are deployed in the field and inturn having applications compiled against current version of uclibc directly communicating on the internet for dns lookup/resolution using uclibc's logic, would be vulnerable.

Once uclibc is updated, the applications / firmware of the devices would need to be updated by the device vendors and or open firmware teams.

Also do note that the patch/update that will be released is not a fool proof solution to the underlying problem. It makes the problem more difficult from a attackers perspective, but not necessarily impossible in all cases. And this particular aspect is independent of uclibc. The use of a secure dns variant is the more long term solution.

NOTE: My normal work is bit different from this specific domain. So do forgive my more generic thoughts, as I havent looked into the specific implementations out there currently wrt this chain.