6 May
2022
6 May
'22
8:34 p.m.
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.