[strongSwan] DH group for key exchange is undefined

[Michael Chan]

Hi Tobias,
      I tried doing a make uninstall and and did a apt-get remove
strongswan on the system. Then I rebuild strongswan again, but I got the
same result I did a packet capture and still the KE payload DH group is 0.
This is what I see in the logs now. I am running strongswan on Kali 2.0




charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux
4.0.0-kali1-amd64, x86_64)
charon: 00[CFG] loaded load-tester address pool 2.2.2.20/24 on eth1
charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
charon: 00[CFG] loading ocsp signer certificates from
'/etc/ipsec.d/ocspcerts'
charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
charon: 00[CFG] expanding file expression
'/var/lib/strongswan/ipsec.secrets.inc' failed
charon: 00[LIB] loaded plugins: charon aes agent gcm openssl des rc2 sha1
sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8
pkcs12 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr load-tester
kernel-netlink resolve socket-default stroke updown xauth-generic
charon: 00[JOB] spawning 16 worker threads
charon: 07[CFG] assigning new lease to 'ext-2'
charon: 07[CFG] installed load-tester IP 2.2.2.20 on eth1
charon: 07[IKE] initiating IKE_SA load-test[1] to 2.2.2.1
charon: 07[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) N(HASH_ALG) ]
charon: 07[NET] sending packet: from 2.2.2.20[500] to 2.2.2.1[500] (288
bytes)
charon: 11[CFG] assigning new lease to 'ext-3'
charon: 11[CFG] installed load-tester IP 2.2.2.21 on eth1
charon: 11[IKE] initiating IKE_SA load-test[2] to 2.2.2.1
charon: 11[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) N(HASH_ALG) ]
charon: 11[NET] sending packet: from 2.2.2.21[500] to 2.2.2.1[500] (288
bytes)
charon: 08[IKE] retransmit 1 of request with message ID 0
charon: 08[NET] sending packet: from 2.2.2.21[500] to 2.2.2.1[500] (288
bytes)
charon: 09[IKE] retransmit 1 of request with message ID 0
charon: 09[NET] sending packet: from 2.2.2.20[500] to 2.2.2.1[500] (288
bytes)
charon: 10[IKE] retransmit 2 of request with message ID 0
charon: 10[NET] sending packet: from 2.2.2.21[500] to 2.2.2.1[500] (288
bytes)
charon: 12[IKE] retransmit 2 of request with message ID 0
charon: 12[NET] sending packet: from 2.2.2.20[500] to 2.2.2.1[500] (288
bytes)
charon: 13[IKE] retransmit 3 of request with message ID 0


On Fri, Feb 5, 2016 at 6:31 AM, Tobias Brunner <tobias at strongswan.org>
wrote:

> Hi Michael,
>
> I think the reason why no DH group is set in the KE payload and you get
> a segmentation fault is that you are mixing an old crypto plugin with a
> newer build of the daemon/libraries.
>
> The 5.3.1 release added a new method to the diffie_hellman_t interface.
>  It was added at the position where the get_dh_group() getter was in
> previous releases:
>
>   get_my_public_value()
>  +set_private_value()
>   get_dh_group()
>   destroy()
>
> Which means that get_dh_group() is now at the position destroy() was
> previously.  So any code built against the current version of the
> diffie_hellman.h header file that calls get_dh_group() for a DH
> implementation provided by a plugin built against the previous header
> file will actually call destroy() instead.  Since there won't be a
> return value the DH group is basically undefined and at the same time
> the DH object is destroyed, causing a segmentation fault when the object
> is accessed later on (in your case when the DH object is accessed in
> ike_init_t.migrate()).
>
> When upgrading from sources it is recommended to call `make uninstall`
> in the _original_ build directory (i.e. where you called `make install`
> previously), which will remove binaries but leave configuration files
> alone.  So keep that build directory around.  If you don't want or can
> do that at least use the same ./configure options (the options used for
> a previous build can be seen at the top of the config.log file in the
> build directory).  Of course, you can also remove the binaries manually
> before running `make install` for the new build.  Their location depends
> on the configured --prefix and other options to specify installation
> paths.  By default plugins are installed in `/usr/local/lib/ipsec/plugins`.
>
> Regards,
> Tobias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160205/b5526e98/attachment.html>