Fedora has issued an advisory on December 11:
Updated packages uploaded for Mageia 5, Mageia 6, and Cauldron.
My understanding, based on what I said in Bug 17910, is that OMAPI has to be explicitly enabled and isn't really considered safe when accepting untrusted connections, so this one should be a minor issue.
Updated dhcp packages fix security vulnerability:
It was found that the DHCP daemon does not free socket descriptors when
handling empty OMAPI messages. An adjacent network attacker could potentially
use this flaw to send crafted OMAPI messages to the DHCP daemon, thereby
leading to denial of service due to exhaustion of file descriptors in the
DHCP daemon process.
Updated packages in core/updates_testing:
Mageia 5 :: x86_64
Installed all packages except the server and rebooted the machine. Could not think of any other way to test the update. Nothing relevant in the services list. No networking issues either local or global.
Passing this for 64 bits on Mageia 5.
For testing this, https://bugs.mageia.org/show_bug.cgi?id=17462
comments 4 & 5 look useful.
If someone can say how to apply that logic to a stand-alone system with Ethernet connection to a DSL box, the interface configured as automatic everything (get from the gateway, DHCP included) - I will try this.
@Lewis: the test you mention above is nothing more than Len just did, just a bit better explained. I coudn't think of anything better, so I did the same test without any apparent ill effects. OK for me.
Can be validated for M5.
MGA5TOO MGA5-64-OK =>
MGA5TOO MGA5-64-OK MGA5-32-OKCC:
Before the update, all pkgs were at version 4.3.5-1. Only'common' & 'client' were installed, I added 'relay' & 'server", but clearly these are not used on my system. Updated to:
Re-booted. dhcpd is running:
# systemctl status dhcpd
● dhcpd.service - DHCPv4 Server Daemon
Loaded: loaded (/usr/lib/systemd/system/dhcpd.service; enabled; vendor preset
Active: active (running) since Iau 2017-12-21 14:06:22 CET; 20min ago
Process: 1428 ExecStart=/usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf $CONFIGFI
Main PID: 1589 (dhcpd)
└─1589 /usr/sbin/dhcpd -pf /run/dhcpd/dhcpd.pid -cf /etc/dhcpd.conf -
Rha 21 14:06:19 localhost.localdomain systemd: Starting DHCPv4 Server Daemon.
Rha 21 14:06:20 localhost.localdomain dhcpd: WARNING: Host declarations ar
Rha 21 14:06:20 localhost.localdomain dhcpd: ldap_gssapi_principal is not
Rha 21 14:06:20 localhost.localdomain dhcpd: Not searching LDAP since ldap
Rha 21 14:06:20 localhost.localdomain dhcpd: Source compiled to use binary
Rha 21 14:06:20 localhost.localdomain dhcpd: Wrote 0 deleted host decls to
Rha 21 14:06:20 localhost.localdomain dhcpd: Wrote 0 new dynamic host decl
Rha 21 14:06:20 localhost.localdomain dhcpd: Wrote 0 leases to leases file
Rha 21 14:06:22 localhost.localdomain dhcpd: Server starting service.
Rha 21 14:06:22 localhost.localdomain systemd: Started DHCPv4 Server Daemon.
I have tried localhost and various remote (via gateway) Internet access, all going as normal. In the light of earlier comments about not being able to do much more, OKing & validating.
MGA5TOO MGA5-64-OK MGA5-32-OK =>
MGA5TOO MGA5-64-OK MGA5-32-OK MGA6-64-OKCC:
An update for this issue has been pushed to the Mageia Updates repository.
ISC has issued an advisory for this today:
They finally publicly acknowledged the issue and allocated a CVE.
If someone could update the advisory in SVN with the CVE and reference, that'd be great.
dhcp new DoS security due to socket descriptor leak in omapi (isc-bugs#46767) =>
dhcp new DoS security due to socket descriptor leak in omapi (isc-bugs#46767, CVE-2017-3144)
(In reply to David Walser from comment #6)
Added to references.
> They finally publicly acknowledged the issue and allocated a CVE.
CVE-2017-3144 : Failure to properly clean up closed OMAPI connections can exhaust available sockets.
> If someone could update the advisory in SVN with the CVE and reference,
> that [woul]d be great.
Your wish is my command! Done.