Point to Point Protocol Daemon demonized by CVE-2020-8597

A critical 17-year-old remote code execution bug was discovered in pppd (Point to Point Protocol Daemon). PPPD is used to manage network connections between two nodes on Unix-like operating systems and is responsible for managing PPP session establishment and session termination.

The vulnerability, tracked as CVE-2020-8597, is a flaw in the Extensible Authentication Protocol (EAP) packet processing of PPPD. EAP is an authentication framework that PPPD uses to authenticate a network connected peer and/or supply authentication information to the peer.

CVE-2020-8597 can be classified as a classic buffer overflow vulnerability (CWE-120).  As in most cases, an unauthenticated remote attacker can execute arbitrary code on the system by overflowing the stack buffer.

The code fails to validate the size of the input before copying it to the memory. This simple flaw allows copying of arbitrary data into memory and therefore memory corruption and execution of arbitrary code on the target.

The issue has been identified in eap parsing code of functions eap_request() and eap_response() in file eap.c. The functions eap_request() and eap_response() are called by a network input handler and accept pointer and length as inputs with the first byte as type. The EAP in PPP uses the MD5-Challenge mechanism as specified in RFC 2284 (PPP Extensible Authentication Protocol (EAP)).

Fig.Implementation of MD5-Challenge mechanism in pppd

If the type identified is EAPT_MD5CHAP(4), then it checks for the embedded 1-byte length field. The code checks to make sure that the embedded length is smaller than the whole packet length. After this verification, the supplied input data is copied to a local stack buffer. But, the bounds check here was identified as incorrect and it therefore allowed copying data of any length into the memory.

Another logical flaw in the code complements the existing code execution bug. The second flaw is present in the function eap_input(), which fails to check for EAP negotiation during the Line Control Protocol (LCP) phase. The LCP is an important protocol that is responsible for overall successful operation and supervising of the actions of other PPP protocols.

Due to failure in verification of successful EAP negotiation, PPP will accept and process EAP packets from an unauthenticated attacker, even if it had refused the authentication negotiation due to the lack of support for EAP or due to a mismatch of an agreed pre-shared passphrase in the LCP phase. Thus, unverified data with an arbitrary length can be used to overflow the stack buffer and corrupt the memory. PPPD runs with high privileges and works in conjunction with kernel drivers on a machine, and therefore, it facilitates the execution of arbitrary code with system or root privileges.

The code in eap_request() and eap_response() functions of eap.c has been corrected in the latest patches to eliminate the said flaw as shown below:

Fig.Code correction to eliminate CVE-2020-8597

Affected Products

pppd (Point to Point Protocol Daemon) version 2.4.2 through 2.4.8 on popular Linux distributions including Debian, Ubuntu, SUSE Linux, Fedora, NetBSD, Red Hat Enterprise Linux are known to be affected by this vulnerability. Additionally, small devices with pppd capabilities which have specifically configured lwIP source code to enable EAP at compile time are likely vulnerable. The following other products are also known to be impacted:


An unauthenticated remote attacker can send EAP packets to a vulnerable ppp client or server to corrupt the memory by overflowing the buffer and also execute arbitrary code with system or root privileges.


Please refer to this KB Article to apply the patches using SanerNow.


Subscribe For More Posts Like This

Get the latest research, best practices, industry trends and cybersecurity blogs from SecPod security experts

Invalid email address
We promise not to spam you. You can unsubscribe at any time.
0 0 vote
Article Rating
Notify of
1 Comment
Inline Feedbacks
View all comments
John Cowell

Great post here..thanks for sharing