[Openswan dev] endian bug
Paul Wouters
paul at xelerance.com
Fri Jul 8 15:28:13 EDT 2011
On Fri, 8 Jul 2011, Magnus Öberg wrote:
[ forwarded to dev at openswan.org ]
Magnus: I've applied your fix to git and it will be in 2.6.35.
Paul
> Date: Fri, 08 Jul 2011 15:01:42 +0200
> From: Magnus Öberg <magnus.oberg at westermo.se>
> To: <paul at xelerance.com>
> Subject: Bug report OpenSwan
>
> Hi!
>
> I hope I'm mailing the correct person for this.
>
> I've discovered a bug when using OpenSwan as responder on a little-endian
> system and using ID_FQDN as local ID on the openswan side.
>
> I kept on getting this failure in the logs:
> "ipsec0"[1] 10.0.0.1 #1: received Hash Payload does not match computed value
>
> With debug output I saw this:
>
> May 3 12:24:35 lynx pluto[878]: | *received 60 bytes from 10.0.0.1:500 on
> vlan2 (port=500)
> May 3 12:24:35 lynx pluto[878]: | 14 23 a1 89 5e b9 67 78 82 eb e5 c8 aa
> 3b 86 a3
> May 3 12:24:35 lynx pluto[878]: | 08 10 04 01 00 00 00 00 00 00 00 3c f7
> 18 99 a6
> May 3 12:24:35 lynx pluto[878]: | b7 9a 37 81 6e 43 03 02 ed e4 39 9a d8
> 11 3e e8
> May 3 12:24:35 lynx pluto[878]: | ee 00 b1 13 84 8f e8 51 cf b2 5c c7
> May 3 12:24:35 lynx pluto[878]: | **parse ISAKMP Message:
> May 3 12:24:35 lynx pluto[878]: | initiator cookie:
> May 3 12:24:35 lynx pluto[878]: | 14 23 a1 89 5e b9 67 78
> May 3 12:24:35 lynx pluto[878]: | responder cookie:
> May 3 12:24:35 lynx pluto[878]: | 82 eb e5 c8 aa 3b 86 a3
> May 3 12:24:35 lynx pluto[878]: | next payload type: ISAKMP_NEXT_HASH
> May 3 12:24:35 lynx pluto[878]: | ISAKMP version: ISAKMP Version 1.0
> (rfc2407)
> May 3 12:24:35 lynx pluto[878]: | exchange type: ISAKMP_XCHG_AGGR
> May 3 12:24:35 lynx pluto[878]: | flags: ISAKMP_FLAG_ENCRYPTION
> May 3 12:24:35 lynx pluto[878]: | message ID: 00 00 00 00
> May 3 12:24:35 lynx pluto[878]: | length: 60
> May 3 12:24:35 lynx pluto[878]: | processing version=1.0 packet with
> exchange type=ISAKMP_XCHG_AGGR (4)
> May 3 12:24:35 lynx pluto[878]: | ICOOKIE: 14 23 a1 89 5e b9 67 78
> May 3 12:24:35 lynx pluto[878]: | RCOOKIE: 82 eb e5 c8 aa 3b 86 a3
> May 3 12:24:35 lynx pluto[878]: | state hash entry 21
> May 3 12:24:35 lynx pluto[878]: | v1 peer and cookies match on #1, provided
> msgid 00000000 vs 00000000
> May 3 12:24:35 lynx pluto[878]: | v1 state object #1 found, in STATE_AGGR_R1
> May 3 12:24:35 lynx pluto[878]: | processing connection ipsec0[1] 10.0.0.1
> May 3 12:24:35 lynx pluto[878]: | received encrypted packet from 10.0.0.1:500
> May 3 12:24:35 lynx pluto[878]: | decrypting 32 bytes using algorithm
> OAKLEY_AES_CBC
> May 3 12:24:35 lynx pluto[878]: | decrypted:
> May 3 12:24:35 lynx pluto[878]: | 00 00 00 18 f0 c9 c9 55 8c 28 06 3d 18
> 40 75 a0
> May 3 12:24:35 lynx pluto[878]: | 23 50 10 83 0e d7 2e 0a 00 00 00 00 00
> 00 00 00
> May 3 12:24:35 lynx pluto[878]: | next IV: d8 11 3e e8 ee 00 b1 13 84 8f
> e8 51 cf b2 5c c7
> May 3 12:24:35 lynx pluto[878]: | got payload 0x100(ISAKMP_NEXT_HASH) needed:
> 0x100 opt: 0x102000
> May 3 12:24:35 lynx pluto[878]: | ***parse ISAKMP Hash Payload:
> May 3 12:24:35 lynx pluto[878]: | next payload type: ISAKMP_NEXT_NONE
> May 3 12:24:35 lynx pluto[878]: | length: 24
> May 3 12:24:35 lynx pluto[878]: | removing 8 bytes of padding
> May 3 12:24:35 lynx pluto[878]: | **emit ISAKMP Identification Payload (IPsec
> DOI):
> May 3 12:24:35 lynx pluto[878]: | next payload type: ISAKMP_NEXT_NONE
> May 3 12:24:35 lynx pluto[878]: | ID type: ID_FQDN
> May 3 12:24:35 lynx pluto[878]: | Protocol ID: 17
> May 3 12:24:35 lynx pluto[878]: | port: 62465
> May 3 12:24:35 lynx pluto[878]: | emitting 5 raw bytes of my identity into
> ISAKMP Identification Payload (IPsec DOI)
> May 3 12:24:35 lynx pluto[878]: | my identity 64 72 32 35 30
> May 3 12:24:35 lynx pluto[878]: | emitting length of ISAKMP Identification
> Payload (IPsec DOI): 13
> May 3 12:24:35 lynx pluto[878]: | ***parse ISAKMP Identification Payload:
> May 3 12:24:35 lynx pluto[878]: | next payload type: ISAKMP_NEXT_NONE
> May 3 12:24:35 lynx pluto[878]: | length: 13
> May 3 12:24:35 lynx pluto[878]: | ID type: ID_FQDN
> May 3 12:24:35 lynx pluto[878]: | DOI specific A: 17
> May 3 12:24:35 lynx pluto[878]: | DOI specific B: 62465
> May 3 12:24:35 lynx pluto[878]: | hashing 52 bytes of SA
> May 3 12:24:35 lynx pluto[878]: | received HASH: f0 c9 c9 55 8c 28 06 3d
> 18 40 75 a0 23 50 10 83
> May 3 12:24:35 lynx pluto[878]: | received HASH: 0e d7 2e 0a
> May 3 12:24:35 lynx pluto[878]: "ipsec0"[1] 10.0.0.1 #1: received Hash
> Payload does not match computed value
>
>
> The weird thing is the lines:
> May 3 12:24:35 lynx pluto[878]: | port: 62465
> and
> May 3 12:24:35 lynx pluto[878]: | DOI specific B: 62465
>
> That port number turns out to be "500" with the wrong endian.
>
> I narrowed it down to these code lines:
> programs/pluto/ikev1_aggr.c
>
> 874 /* interop ID for SoftRemote & maybe others ? */
> 875 id_hd.isaiid_protoid = st->st_peeridentity_protocol;
> 876 id_hd.isaiid_port = htons(st->st_peeridentity_port);
> 877
>
> and
> programs/pluto/ipsec_doi.c
>
> 602 /*
> 603 * For interop with SoftRemote/aggressive mode we need to
> remember some
> 604 * things for checking the hash
> 605 */
> 606 st->st_peeridentity_protocol = id->isaid_doi_specific_a;
> 607 st->st_peeridentity_port = id->isaid_doi_specific_b;
> 608
>
>
> The st_peeridentity_port is copied from the DOI fields as it is (as wrong
> endian on little-endian systems),
> but is converted properly when setting up the ID structure (struct
> isakmp_ipsec_id id_hd) that is
> used to build the HMAC.
>
> Other entries in struct state seem to be in native format, so I guess the
> place to fix it is in
> ipsec_doi.c:
> 607 st->st_peeridentity_port = ntohs(id->isaid_doi_specific_b);
>
>
> This seems to fix the problem.
> I have had the opportunity to test on a big-endian system with the exact same
> setup, and it seems to work with this fix.
>
> Let me know if you need more info from me!
>
> Best regards
> Magnus Öberg
> Westermo R&D
> Västerås, Sweden
>
>
>
More information about the Dev
mailing list