| Summary: | <net-misc/dhcpcd-6.10.0: two vulnerabilities (CVE-2016-{1503,1504}) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | base-system, roy, williamh, zerochaos |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2016/01/07/3 | ||
| Whiteboard: | A2 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
@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 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). |
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.