Comment 9 for bug 1549436

Revision history for this message
ruslan_ka (r-kalakutsky) wrote : Re: AppArmor kills StronSwan daemon 'charon'

Hello Simon,

I'm not really sure should I post it here, report a new bug, or report a bug to strongswan project directly.

I can reproduce this buffer overflow with 100% probability. It is a resource independent and strongswan fail as on t1.micro or at any instance with more resources.

Buffer overflow depends on a connections number (few hundreds - from 150 up to almost 400 - it depends on time between connections ).

Some other resources usage:
* CPU load less than 50% on t1.micro and less than 10% on t1.lagre - https://www.dropbox.com/s/kqox2t2u86ws49c/Screenshot%202016-02-27%2018.51.01.png?dl=0 (green)
* a lot of free memory - https://www.dropbox.com/s/vzah4itqmrioksn/Screenshot%202016-02-27%2018.50.45.png?dl=0
* about 1100 sockets are used - https://www.dropbox.com/s/vkqf4ziuz19m20f/Screenshot%202016-02-27%2018.50.18.png?dl=0
* write peak 90kB/sec (/var/log) - https://www.dropbox.com/s/6kyt81lh4wnmh5h/Screenshot%202016-02-27%2018.50.30.png?dl=0

ipsec statusall before fail:

xd@test-vpn-01:~$ sudo ipsec statusall | head -4
Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-74-generic, x86_64):
  uptime: 83 seconds, since Feb 27 18:02:36 2016
  malloc: sbrk 4870144, mmap 0, used 4382032, free 488112
  worker threads: 507 of 512 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 876
xd@test-vpn-01:~$ sudo ipsec statusall | head -4
Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-74-generic, x86_64):
  uptime: 85 seconds, since Feb 27 18:02:36 2016
  malloc: sbrk 4927488, mmap 0, used 4428240, free 499248
  worker threads: 507 of 512 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 889
xd@test-vpn-01:~$ sudo ipsec statusall | head -4
Status of IKE charon daemon (strongSwan 5.1.2, Linux 3.13.0-74-generic, x86_64):
  uptime: 86 seconds, since Feb 27 18:02:36 2016
  malloc: sbrk 4980736, mmap 0, used 4488352, free 492384
  worker threads: 506 of 512 idle, 5/0/1/0 working, job queue: 0/0/0/0, scheduled: 897
xd@test-vpn-01:~$ sudo ipsec statusall | head -4
xd@test-vpn-01:~$ sudo ipsec statusall | head -4

# cat log.txt | grep -B 20 -A 20 'overflow'
216[CFG] received RADIUS Access-Accept from server '127.0.0.1'
216[CFG] scheduling RADIUS Interim-Updates every 15s
216[IKE] RADIUS authentication of 'loadtest-197' successful
216[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
216[ENC] generating IKE_AUTH response 4 [ EAP/SUCC ]
216[NET] sending packet: from 172.31.59.95[500] to 172.31.62.150[500] (76 bytes)
217[NET] received packet: from 172.31.62.150[500] to 172.31.59.95[500] (92 bytes)
217[ENC] parsed IKE_AUTH request 5 [ AUTH ]
217[IKE] authentication of 'loadtest-197' with EAP successful
217[IKE] authentication of 'CN=srv, OU=load-test, O=strongSwan' (myself) with EAP
217[IKE] IKE_SA ikev2-with-eap-loadtest[248] established between 172.31.59.95[CN=srv, OU=load-test, O=strongSwan]...172.31.62.150[loadtest-197]
217[IKE] scheduling reauthentication in 3403s
217[IKE] maximum IKE_SA lifetime 3583s
217[IKE] peer requested virtual IP %any
217[CFG] assigning new lease to 'loadtest-197'
217[IKE] assigning virtual IP 10.0.0.231 to peer 'loadtest-197'
217[IKE] CHILD_SA ikev2-with-eap-loadtest{231} established with SPIs c8213004_i cd74929b_o and TS 172.31.59.95/32 === 10.0.0.231/32
217[CFG] sending RADIUS Accounting-Request to server '127.0.0.1'
217[CFG] received RADIUS Accounting-Response from server '127.0.0.1'
217[ENC] generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) ]
217[NET] sending packet: from 172.31.59.95[500] to 1*** buffer overflow detected ***: /usr/lib/ipsec/charon terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7338f)[0x7f81b0aa038f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f81b0b37c9c]
/lib/x86_64-linux-gnu/libc.so.6(+0x109b60)[0x7f81b0b36b60]
/lib/x86_64-linux-gnu/libc.so.6(+0x10abe7)[0x7f81b0b37be7]
/usr/lib/ipsec/libradius.so.0(+0x2fcf)[0x7f81ab867fcf]
/usr/lib/ipsec/libradius.so.0(+0x3660)[0x7f81ab868660]
/usr/lib/ipsec/plugins/libstrongswan-eap-radius.so(+0x4af1)[0x7f81aba70af1]
/usr/lib/ipsec/plugins/libstrongswan-eap-radius.so(+0x4dc5)[0x7f81aba70dc5]
/usr/lib/ipsec/libstrongswan.so.0(+0x2858e)[0x7f81b14b258e]
/usr/lib/ipsec/libstrongswan.so.0(+0x28df2)[0x7f81b14b2df2]
/usr/lib/ipsec/libstrongswan.so.0(+0x2bc14)[0x7f81b14b5c14]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7f81b0dfa182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f81b0b2747d]
======= Memory map: ========
7f8064000000-7f8064050000 rw-p 00000000 00:00 0
7f8064050000-7f8068000000 ---p 00000000 00:00 0
7f806c000000-7f806c042000 rw-p 00000000 00:00 0
7f806c042000-7f8070000000 ---p 00000000 00:00 0
7f8070000000-7f8070038000 rw-p 00000000 00:00 0

After full update the bug still exist:

# lsb_release -rd
Description: Ubuntu 14.04.4 LTS
Release: 14.04

# ipsec --version
Linux strongSwan U5.1.2/K3.13.0-79-generic
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil, Switzerland
See 'ipsec --copyright' for copyright information.

# apt-cache policy libc-bin
libc-bin:
  Installed: 2.19-0ubuntu6.7
  Candidate: 2.19-0ubuntu6.7
  Version table:
 *** 2.19-0ubuntu6.7 0
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.19-0ubuntu6 0
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

# apt-cache policy strongswan
strongswan:
  Installed: 5.1.2-0ubuntu2.4
  Candidate: 5.1.2-0ubuntu2.4
  Version table:
 *** 5.1.2-0ubuntu2.4 0
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     5.1.2-0ubuntu2 0
        500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

# uname -a
Linux test-vpn-01 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Best regards,
Ruslan.