Skip to content

Latest commit

 

History

History
 
 

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 

README.md

Buffer overflow in strongSwan VPN's charon server (CVE-2018-5388)

This directory contains a proof-of-concept exploit for a buffer overflow vulnerability in strongSwan VPN's charon daemon. The vulnerability was discovered by Kevin Backhouse of the Semmle Security Research Team and has been assigned CVE-2018-5388. It was fixed in strongSwan version 5.6.3, which was released on 28 May 2018.

The bug

The bug is in this code (src/libcharon/plugins/stroke/stroke_socket.c:634):

if (!stream->read_all(stream, (char*)msg + sizeof(len), len - sizeof(len)))

The value of len is read from a socket (on line 621), so it could be vulnerable to attack. The code does not check that len >= sizeof(len), so the calculation of len - sizeof(len) could overflow negatively and produce a very large value (of type size_t). This will cause a heap buffer overflow in the call to read_all, because the size of the msg buffer is very small and read_all will keep reading data from the socket until the connection is closed (or it reads 2^64 bytes).

Running the PoC

To demonstrate the PoC in a safe environment, we will run the vulnerable version of strongSwan in a docker container.

First, build the docker image:

docker build . -t strongswan

As you can see from the Dockerfile, we have installed strongSwan version 5.6.2. We have also created a user named "attacker". This user is a member of the vpn group, so that they can use the stroke utility to query the charon daemon. The attacker does not get other special privileges though. For example, they do not have superuser privileges.

Now start the container:

docker run --privileged -i -t strongswan

The --privileged flag is needed to start ipsec inside the container. Do this now:

ipsec start

Now switch to the attacker user account:

su - attacker

And run the attack:

./strongswan/src/stroke/.libs/stroke statusall

You will see an error message like this:

ipsec_starter[26]: charon has died -- restart scheduled (5sec)

The charon daemon crashed due to a buffer overflow which we triggered by sending it a malicious message.