[Openswan Users] Pluto Segmentation fault in 2.4.7

[Paul Wouters]

On Mon, 5 Mar 2007, Pompon wrote:

> Subject: Re: [Openswan Users] Pluto Segmentation fault in 2.4.7
>
> Following our last week experiment with Segmentation fault, we moved the
> connection to a staging platform, and we've got a backtrace of the bug :

> #0  fmt_log (buf=0xbfe61780 "", buf_len=1024, fmt=0x80bdf20 "ASSERTION
> FAILED at %s:%lu: %s", ap=0x0) at log.c:149
> 149             snprintf(bp, be - bp, "\"%s\"", c->name);
>
> (gdb) bt
> #0  fmt_log (buf=0xbfe61780 "", buf_len=1024, fmt=0x80bdf20 "ASSERTION
> FAILED at %s:%lu: %s", ap=0x0) at log.c:149
> #1  0x08056cd1 in openswan_loglog (mess_no=135371408, message=0x8119a90

The logging routines in 2.4.7 had a problem with displaying certain
options. Can you verify that openswan 2.4.8rc1 (available in the testing/
subdirectory) still has this problem? It looks like a diffrent bug, but
before we start hunting ghosts, I'd like to be sure.

> "Hy\227\021\b", '' <repeats 192 times>...) at log.c:434
> #2  0x08057c30 in passert_fail (pred_str=0x8119a90 "Hy\227\021\b", ''
> <repeats 192 times>...,
>    file_str=0x8119a90 "Hy\227\021\b", '' <repeats 192 times>...,
> line_no=135371408) at log.c:606
> #3  0x0807b3c4 in complete_state_transition (mdp=0x80edd6c,
> result=STF_INLINE) at demux.c:2738
> #4  0x080795f5 in process_packet (mdp=0x80edd6c) at demux.c:2352
> #5  0x0807bcbc in comm_handle (ifp=0x8116500) at demux.c:1223
> #6  0x0805d070 in call_server () at server.c:1166
> #7  0x0805b0d1 in main (argc=12, argv=0xbfe62264) at plutomain.c:787
>
>
> The PFS is declared on both side, and our partner use a linksys VPN (and not
> openswan as I first thought). Applying the Matthias's patch make pluto not
> crashing even if the tunnels don't go up. In this case, here is the related
> auth-log :

What was Matthias's patch?

> Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10: responding
> to Main Mode
> Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
> Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM
> Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Mar 5 10:12:52 tamerlane pluto[12459]: "faulty_connection" #10:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Mar 5 10:12:55 tamerlane pluto[12459]: "faulty_connection" #10: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Mar 5 10:12:55 tamerlane pluto[12459]: "faulty_connection" #10:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: Main mode
> peer ID is ID_IPV4_ADDR: '222.126.123.139'
> Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: I did not
> send a certificate because I do not have one.
> Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY
> cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
> Mar 5 10:13:10 tamerlane pluto[12459]: "faulty_connection" #10: Dead Peer
> Detection (RFC 3706): not enabled because peer did not advertise it
> Mar 5 10:13:11 tamerlane pluto[12459]: "faulty_connection" #11: only
> OAKLEY_GROUP_MODP1024 and OAKLEY_GROUP_MODP1536 supported for PFS
> Mar 5 10:13:11 tamerlane pluto[12459]: "faulty_connection" #11: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 222.126.123.139:500

The other end is configured with 1des/3des and DH group1 (modp768) which are too
weak and not supported per default on openswan. But of course, we shouldn't
crash on this.

> Switching off the PFS on both side make the tunnel works using either the
> patched or not patched pluto binary.

Yes, then you are not stuck on the remote's flawed proposal of modp768.

I guess we didnt catch this because our automatic testing all uses the same
pluto binary, so either both ends support or or both ends do not.

Thanks for the report,

Paul