Stork 2.0: Open Source DHCP Management Tool
ISC launched the Stork management application almost exactly five years ago, in November 2019, as an experimental tool.
Read post
We are aware of the Log4J/Log4JShell vulnerability published recently. Several users have asked if ISC software is exposed to this vulnerability.
None of our currently-supported versions of BIND 9, Kea, and ISC DHCP as published by ISC includes Java code or links to the Log4J logging utility. We have also checked our published BIND Docker image, and that does not include Log4J in the image. It is possible that third-party packaged versions of our software have been modified to somehow use Log4J, so if you are getting open source from another publisher, you should check that.
Stork users should be aware that Grafana, an open source application used for visualizing data from Stork, is vulnerable to a different 0-day vulnerability and must be patched. Grafana is included in the Stork ‘demo’, which should not be used in production. The Swagger API generator used by Stork is technically vulnerable to Log4j, but the vulnerable component is only used while testing Swagger, and a ‘regular user’ is not exposed.
ISC follows a published process for assessing security vulnerabilities in our software. This is documented here: ISC Software Defect and Security Vulnerability Disclosure Policy.
If you suspect you have found a security defect in BIND, DHCP, or Kea, or if you wish to inquire about a security issue that you have learned about which has not yet been publicly announced, ISC encourages you to get in touch with our Security Officer by following the process described at https://www.isc.org/reportbug/.
Alternatively, you can email us at security-officer@isc.org. However, plain-text e-mail is not a secure choice for communications concerning undisclosed security issues so we ask that you please encrypt your communications to us using the ISC Security Officer public key which can be found on our website at: https://www.isc.org/pgpkey/.
Defects that span multiple DNS implementations
If you believe you have found a security vulnerability that applies to DNS implementations generally, and you want to report this responsibly to a number of implementers, you might consider using the Open Source DNS Vulnerability mailing list, managed by DNS-OARC.
