* Mark Andrews: > And the best way to deal with this is to have manufacturers update > https://www.kb.cert.org/vuls/id/457759 with their status. Yes it > should be a much bigger list than what is there. Every IoT vendor. > Every router vendor. Every OS vendor. Yes, ISC needs to put in a > offical status. If you have a internet connected product and the > manufacture is not on the list, contact the manufacture and ask > them to provide a status update.
The real challenge are the vendors who do not realize they are embedding a copy of glibc in their product. I'm sure they exist. > The list may have a lot of "affected if run on a vulnerable OS" > responses. For most of these the solution will be "fix the OS, > relink if statically linked, and reboot the machine". Static linking is less of a concern, for once. The reason is that you need to jump through very special hoops to get a statically linked copy of nss_dns which uses a statically linked copy of libresolv. Regular distribution builds for static linking use static dlopen to dynamically link the required NSS libraries. Due to some implementation details, such statically linked binaries are not very portable between different glibc versions, and there's a clear warning at static link time that you need the DSOs for the same glibc version you are statically linking against at run time. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
