From ${URL} : dhcpcd recently fixed two security issues. Can you assign CVE ids to these? http://roy.marples.name/projects/dhcpcd/info/76a1609352263bd9 can lead to a heap overflow via malformed dhcp responses later in print_option (via dhcp_envoption1) due to incorrect option length values. exploitation is non-trivial, but i'd love to be proven wrong. http://roy.marples.name/projects/dhcpcd/info/595883e2a431f65d can lead to an invalid read/crash via malformed dhcp responses. not exploitable beyond DoS as far as I can judge. @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
@security: 6.10.0 is in ~arch. Do we need a fast stable for this?
(In reply to William Hubbs from comment #1) > @security: > 6.10.0 is in ~arch. Do we need a fast stable for this? yes we do
WARNING about fast stabling this version: some hooks were moved from the hook directory to an example directory, one of which was the hook to start wpa_supplicant if correctly configured. Some users *may* be using this for handling the hotplugging of interfaces, such as a USB wireless stick. I know I did.
A news item is now published for this. Please proceed with fast stabilization. Thanks, William
Arches. please proceed. I've handled amd64 by myself
arm stable
I did not get the news with emerge now using git for sync. Of course I would have found the example hooks at doc: /usr/share/doc/dhcpcd-6.10.0/hooks-examples ? Why the place for a documentory purpose at /usr/share/dhcpcd/hooks ? There is no proper place under /etc to place them, like other software would offer e.g: /etc/dhcpcd/hooks.d
(In reply to Ulenrich from comment #7) > I did not get the news with emerge now using git for sync. Of course I would > have found the example hooks at doc: > /usr/share/doc/dhcpcd-6.10.0/hooks-examples > > ? Why the place for a documentory purpose at /usr/share/dhcpcd/hooks > > ? There is no proper place under /etc to place them, > like other software would offer e.g: /etc/dhcpcd/hooks.d Why not use the appropriate USE flags instead of urging the user to manually copy those files? There are: https://packages.gentoo.org/useflags/wifi https://packages.gentoo.org/useflags/timezone https://packages.gentoo.org/useflags/hostname
(In reply to charles17 from comment #8) > Why not use the appropriate USE flags instead of urging the user to manually > copy those files? > > There are: > https://packages.gentoo.org/useflags/wifi Wifi is too generic a term. wpa_supplicant is more specific as the hook only handles starting/stopping wpa_supplicant in specific scenarios. For BSD at least I am working on a patchset for wpa_supplicant so it work with interface arrival/departures.
Stable for HPPA PPC64.
x86 done
Stable on alpha.
ppc stable
Arch teams, Can we get this version stabilized everywhere so I can remove the vulnerable versions? Thanks, William
Why is this major security bug not stabilized everywhere yet? Is there something I can do to get more movement on it? Thanks, William
the rest are done now
@vapier: Thanks much, it is appreciated. All, All versions <dhcpcd-6.10.0 have been removed from the tree.
New GLSA request filed
CVE-2016-1504 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-1504): dhcpcd is susceptible to an invalid read/crash via malformed DHCP responses. CVE-2016-1503 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-1503): dhcpcd contains a heap overflow via malformed dhcp responses in print_option (via dhcp_envoption1) due to incorrect option length values.
This issue was resolved and addressed in GLSA 201606-07 at https://security.gentoo.org/glsa/201606-07 by GLSA coordinator Kristian Fiskerstrand (K_F).
