[Openswan dev] Pluto crashes with preshared key, responders enabled pfs using 2.4.7

[Matthias Haas]

Hello,
I recently stumbled about a pluto crash while playing around with
different configurations. I currently use openswan-2.4.7 at kernel
2.4.33.3.

The crash seems to affect the responder to a preshared key connection,
where just the responder has pfs activated. As soon as the client tries ti
setup phase 2 the responder crashes. The initiator is not hit by this
crash. At the moment I do not have the time to check whether this also
affects non psk connection.

This is what the responder logs out:

packet from 192.168.0.189:500: received Vendor ID payload [Openswan (this
version) 2.4.7  PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR]
 pluto[25759]: packet from 192.168.0.189:500: received Vendor ID payload
[Dead Peer Detection]
 pluto[25759]: packet from 192.168.0.189:500: received Vendor ID payload
[RFC 3947] method set to=110
 pluto[25759]: packet from 192.168.0.189:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
 pluto[25759]: packet from 192.168.0.189:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
 pluto[25759]: packet from 192.168.0.189:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
 pluto[25759]: packet from 192.168.0.189:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-00]
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: responding to Main Mode from unknown peer 192.168.0.189
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: transition from state STATE_MAIN_R0 to state
STATE_MAIN_R1
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: STATE_MAIN_R1: sent MR1, expecting MI2
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal):
no NAT detected
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: transition from state STATE_MAIN_R1 to state
STATE_MAIN_R2
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: STATE_MAIN_R2: sent MR2, expecting MI3
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.189'
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: I did not send a certificate because I do not have one.
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: transition from state STATE_MAIN_R2 to state
STATE_MAIN_R3
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5
group=modp1536}
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #2: we require PFS but Quick I1 SA specifies no
GROUP_DESCRIPTION
 pluto[25759]: "server_1-toclient_gw-gw_192.168.0.188-0.0.0.0"[1]
192.168.0.189 #2: sending encrypted notification NO_PROPOSAL_CHOSEN to
192.168.0.189:500
 ipsec__plutorun: /usr/local/lib/ipsec/_plutorun: line 1: 25759
Segmentation fault      (core dumped) /usr/local/libexec/ipsec/pluto
--nofork --secretsfile /etc/ipsec.secrets --ipsecdir /etc/ipsec.d
--use-auto --uniqueids --nat_traversal --nhelpers 0

gdb prints out the following stack trace:

149             snprintf(bp, be - bp, "\"%s\"", c->name);
(gdb) backtrace
#0  fmt_log (buf=0xbfffeec8 "", buf_len=1024, fmt=0x80b2c40 "ASSERTION
FAILED at %s:%lu: %s", ap=0xbffff2d8) at log.c:149
#1  0x8055b97 in openswan_loglog (mess_no=3, message=0x80b2c40 "ASSERTION
FAILED at %s:%lu: %s") at log.c:434
#2  0x80564c5 in passert_fail (pred_str=0x80be6a0 "result == STF_IGNORE ||
result == STF_SUSPEND || st->st_calculating==FALSE", file_str=0x80bcc94
"demux.c", line_no=2414) at log.c:606
#3  0x8075633 in complete_state_transition (mdp=0x80e2eec,
result=STF_INLINE) at demux.c:2414
#4  0x80754ef in process_packet (mdp=0x80e2eec) at demux.c:2352
#5  0x807693d in comm_handle (ifp=0x80f7520) at demux.c:1223
#6  0x805c30a in call_server () at server.c:1166
#7  0x80599f6 in main (argc=11, argv=0xbffff874) at plutomain.c:787
#8  0x4006fe5e in __libc_start_main (main=0x8058d54 <main>, argc=11,
ubp_av=0xbffff874, init=0x8049cfc <_init>, fini=0x80ad774 <_fini>,
rtld_fini=0x4000d3c4 <_dl_fini>, stack_end=0xbffff86c)
    at ../sysdeps/generic/libc-start.c:129

It stumbles about a not or still not initialized connection pointer in the
assertion call demux.c 2414 as result is STF_INLINE. As STF_INLINE seems
to be valid here I think the assertion should also be true for this
result. Therefore I applied the following patch:


--- openswan-2.4.7/programs/pluto/demux.c Fri Jan 12 11:35:21 2007
+++ openswan-2.4.7-debug/programs/pluto/demux.c Fri Jan 12 12:16:07 2007
@@ -2411,7 +2411,7 @@
      * we can only be in calculating state if state is ignore,
      * or suspended.
      */
-    passert(result == STF_IGNORE || result == STF_SUSPEND ||
st->st_calculating==FALSE);
+    passert(result == STF_INLINE || result == STF_IGNORE || result ==
STF_SUSPEND || st->st_calculating==FALSE);

     switch (result)
     {

This patch fixed the crash. Atleast it works for me :-)). I do not know
whether this is the right way to get rid of the crash. So please have a
closer look at it.

Kind regards
Matthias