Reporter claims a bad pointer dereference in pppd that could cause an attacker to crash the pppd process. This could lead to a DoS, but he assures that RCE is not possible. Tested on an earlier version than that which is masked in portage. Unconfirmed on the ~ masked version.
Created attachment 42796 [details, diff] cbcp-dosfix.patch The diff of cbcp.c from CVS, which fixes DoS vulnerabilities.
net-dialup, the attached file is the diff of cbcp.c from their CVS tree. This version fixes DoS vulnerabilities mentioned above. Please verify patch, and make sure it doesn't break anything (they changed the way they output debug info).
I spoke with upstream regarding this issue. By default, pppd is not vulnerable to this attack because the line "CBCP=y" is commented out in pppd/Makefile.linux, but our ebuild turns this on, making us vulnerable. 2.4.3 should be getting released hopefully within the next week, and upstream confirmed that applying the cbcp.c diff should work just fine too.
I verified the patch against ppp-2.4.2-r6. src_unpack & src_compile end up successfully. I cannot do more than that since I don't have dev status yet (see bug #63588).
ppp-2.4.2-r7 added with patch. Sorry for the delay.
Thx Daniel. Arches please mark ppp-2.4.2-r7 stable.
Created attachment 42906 [details] Patch failure on sparc
Patch fails miserably...
All I had to do was to copy this patch to files/2.4.2 directory and add at the end of src_unpack the following line: epatch ${FILESDIR}/2.4.2/cbcp-dosfix.patch The result: alin ppp # ebuild ppp-2.4.2-r6.ebuild unpack >>> md5 src_uri ;-) ppp-2.4.2.tar.gz >>> md5 src_uri ;-) ppp-2.4.2-mppe-mppc-1.1.patch.gz >>> md5 src_uri ;-) ppp-dhcpc.tgz >>> Unpacking source... >>> Unpacking ppp-2.4.2.tar.gz to /var/tmp/portage/ppp-2.4.2-r6/work >>> Unpacking ppp-2.4.2-mppe-mppc-1.1.patch.gz to /var/tmp/portage/ppp-2.4.2-r6/work >>> Unpacking ppp-dhcpc.tgz to /var/tmp/portage/ppp-2.4.2-r6/work * Applying mpls.patch.gz ... [ ok ] * Applying killaddr-smarter.patch.gz ... [ ok ] * Applying cflags.patch ... [ ok ] * Applying control_c.patch ... [ ok ] * Disabling active-filter pam * Enabling PAM * Enabling CBCP * Enabling radius * Applying cbcp-dosfix.patch ... [ ok ] >>> Source unpacked.
Arches please test. Dragonheart just fixed the patch in cvs.
Until you commit the patch to cvs and the act of commiting it changes the patch line: #define RCSID "$Id: cbcp.c,v 1.15 2003/01/17 07:23:35 fcusack Exp $" to: #define RCSID "$Id: cbcp-dosfix.patch,v 1.2 2004/10/30 13:49:28 dragonheart Exp $" causing the foresaid misable failure. Patch modified to not change the first hunk (being the above line). Arch marking may resume.
stable on amd64
sparc'd
Stable on alpha.
arm/hppa/ia64 stable
stable on ppc
Ready, security please vote on GLSA need
I vote for a GLSA on this one.
I agree, we need one.
GLSA 200411-01 lewk you might be fast with drafting but closing.....:-)
Stable on mips.