[Swan] [Security] Libreswan 3.29 segfault in ikev2.c ikev2_process_packet()
Alan Szlosek
alan at redoxengine.com
Fri Nov 8 16:30:22 UTC 2019
Inline responses below ....
On Thu, Nov 7, 2019 at 5:53 PM Andrew Cagney <cagney at gnu.org> wrote:
> On Thu, 7 Nov 2019 at 15:54, Alan Szlosek <alan at redoxengine.com> wrote:
> >
> > You're right, I see 0s:
> >
> > (gdb) p md->hdr.isa_msgid
> > $1 = 0
> > (gdb) p st->st_v2_msgids
> > $2 = {current_request = 0, initiator = {sent = 0, recv = 0}, responder =
> {sent = 0, recv = 0}}
> >pr
> > Do you happen to know which commit fixes this? Wondering whether I can
> easily patch it, and/or how long I might have to wait for 3.30.
>
> Not really. The commit was:
>
> commit 0d0a339015e7836c3a120e2d8af18280876b41ee
> Author: Andrew Cagney <cagney at gnu.org>
> Date: Fri May 24 12:15:42 2019 -0400
>
> state: return {ike,child}_sa from find_v2_{ike,child}_sa*()
>
> ... and pass in the IKE_SA when searching for an SA that is
> part of the IKE SA's family.
>
> Re-order the code looking for a state for a message so that it
> first finds the IKE SA and then uses that to find the actual
> state.
>
> but it was part of a whole series of changes.
>
Ah, yeah if the fix was part of a whole series of changes it'll be too
risky to try to bring it in, as other code might cause new issues.
>
> For 3.29 the code looks like:
>
> /*
> * Does the Message ID fall within the IKE SA's
> * sliding Message ID window?
> */
> struct ike_sa *ike = ike_sa(st);
>
> Try adding a check for IKE==NULL here and return when it is.
>
> if (md->hdr.isa_msgid >
> ike->sa.st_v2_msgids.initiator.sent) {
>
Sounds like a safe thing to try given there are plenty of early return
statements elsewhere in that function. And judging from the function
comment it looks like the caller is in charge of freeing md. Are there any
other allocations I should free before returning?
Thanks for the input.
>
>
> > Thanks for diving into this with me, Andrew.
> >
> > On Wed, Nov 6, 2019 at 11:53 PM Andrew Cagney <andrew.cagney at gmail.com>
> wrote:
> >>
> >> [changing lists]
> >>
> >> On Wed, 6 Nov 2019 at 15:30, Alan Szlosek <alan at redoxengine.com> wrote:
> >> >
> >> > Sure, here's everything pertaining to those 2 SAs:
> >> >
> >> > Oct 16 16:07:08 ip-172-20-116-172 pluto[4703]: packet from
> NNNNNNNNNN:4500: EXPECTATION FAILED: child state #533502 missing parent
> state #533497 (in get_ike_sa() at state.c:461)
> >>
> >> I suspect a very small amount of time passes here.
> >>
> >> > Oct 16 16:07:08 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: deleting state (STATE_PARENT_R2) aged 4.913s and sending
> notification
> >>
> >> Like you noted, this happened at the 5s mark so is likely a timeout
> (idle?).
> >>
> >> If you print:
> >> md->hdr.isa_msgid
> >> st->st_v2_msgids
> >> I suspect both hdr.isa_msgid and st_v2_msgids.initiator.sent will be
> zero 0.
> >>
> >> It looks like the response to the above notification was incorrectly
> >> routed to the still being deleted child SA.
> >>
> >> The current code shouldn't have this bug - it should drop any message
> >> with no IKE SA.
> >>
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/1x2"
> #533502: STATE_V2_IPSEC_R: IPsec SA established tunnel mode
> {ESP/NAT=>0xa6587dec <0xb550a3ae xfrm=NNNNNN NATOA=none
> NATD=NNNNNNNNNNNN:4500 DPD=active}
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/1x2"
> #533502: negotiated connection ...
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: received unsupported NOTIFY v2N_NON_FIRST_FRAGMENTS_ALSO
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: proposal 1:ESP:SPI=a6587dec;ENCR=NNNNNN chosen from remote
> proposals...
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: Authenticated using authby=secret
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: IKEv2 mode peer ID is ID_IPV4_ADDR: ‘NNNNNN'
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: processing decrypted IKE_AUTH request:
> SK{V,IDi,AUTH,SA,TSi,TSr,N,N,N}
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: processing encrypted IKE_AUTH request: SK (message arrived 0
> seconds ago)
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2
> cipher=NNNNNNNNN}
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: proposal 2:IKE:ENCR=...
> >> > Oct 16 16:07:03 ip-172-20-116-172 pluto[4703]: "NNNNNNNN/2x3"
> #533497: processing IKE_SA_INIT request: SA,KE,Ni,V,V,N,N,N,V (message
> arrived 0 seconds ago)
> >> >
> >> > On Wed, Nov 6, 2019 at 2:58 PM Andrew Cagney <andrew.cagney at gmail.com>
> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Wed, 6 Nov 2019 at 13:12, Alan Szlosek <alan at redoxengine.com>
> wrote:
> >> >>>
> >> >>> Can do ....
> >> >>>
> >> >>> The parent was indeed deleted.
> >> >>>
> >> >>> I see this:
> >> >>> #533497: received unsupported NOTIFY
> v2N_NON_FIRST_FRAGMENTS_ALSO
> >> >>
> >> >>
> >> >> this log message should be changed to ... - ignored
> >> >>
> >> >>> Then 5 seconds later the deletion:
> >> >>> #533497: deleting state (STATE_PARENT_R2) aged 4.913s and
> sending notification
> >> >>> Followed immediately by the crash:
> >> >>> EXPECTATION FAILED: child state #533502 missing parent state
> #533497 (in get_ike_sa() at state.c:461)
> >> >>>
> >> >>
> >> >> so why was the IKE SA deleted?
> >> >> perhaps post everything relevant; I'd start with <<grep -v -e
> '#533497' -e '#533502'>> with anything sensitive stripped out; but keep an
> eye out for a rekey, history may go back even further
> >> >>
> >> >
> >> >
> >> > --
> >> > Alan Szlosek
> >> > Infrastructure Engineer
> >> > redoxengine.com
> >> >
> >> >
> >> > _______________________________________________
> >> > Swan mailing list
> >> > Swan at lists.libreswan.org
> >> > https://lists.libreswan.org/mailman/listinfo/swan
> >
> >
> >
> > --
> > Alan Szlosek
> > Infrastructure Engineer
> > redoxengine.com
> >
> >
> > _______________________________________________
> > Security mailing list
> > Security at lists.libreswan.org
> > https://lists.libreswan.org/mailman/listinfo/security
>
--
Alan Szlosek
Infrastructure Engineer
redoxengine.com <https://www.redoxengine.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20191108/a19c450a/attachment.html>
More information about the Swan
mailing list