All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nuernberger, Stefan" <snu@amazon.de>
To: "paul@paul-moore.com" <paul@paul-moore.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"Nuernberger, Stefan" <snu@amazon.de>,
	"yujuan.qi@mediatek.com" <yujuan.qi@mediatek.com>,
	"Shah, Amit" <aams@amazon.de>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH net] net/ipv4: defensive cipso option parsing
Date: Mon, 17 Sep 2018 18:02:29 +0000	[thread overview]
Message-ID: <1537207349.7627.32.camel@amazon.de> (raw)
In-Reply-To: <CAHC9VhQ+VKPFmx3R7Ty60KAJhiZwnc2-ZKRYG9w2NSAH7vgnoQ@mail.gmail.com>

On Mon, 2018-09-17 at 12:35 -0400, Paul Moore wrote:
> On Mon, Sep 17, 2018 at 11:12 AM Stefan Nuernberger <snu@amazon.com>
> wrote:
> > 
> > commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop")
> > fixed
> > a possible infinite loop in the IP option parsing of CIPSO. The fix
> > assumes that ip_options_compile filtered out all zero length
> > options and
> > that no other one-byte options beside IPOPT_END and IPOPT_NOOP
> > exist.
> > While this assumption currently holds true, add explicit checks for
> > zero
> > length and invalid length options to be safe for the future. Even
> > though
> > ip_options_compile should have validated the options, the
> > introduction of
> > new one-byte options can still confuse this code without the
> > additional
> > checks.
> > 
> > Signed-off-by: Stefan Nuernberger <snu@amazon.com>
> > Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
> > Reviewed-by: Simon Veith <sveith@amazon.de>
> > Cc: stable@vger.kernel.org
> > ---
> >  net/ipv4/cipso_ipv4.c | 10 ++++++++--
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
> > index 82178cc69c96..f291b57b8474 100644
> > --- a/net/ipv4/cipso_ipv4.c
> > +++ b/net/ipv4/cipso_ipv4.c
> > @@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct
> > cipso_v4_doi *doi_def,
> >   *
> >   * Description:
> >   * Parse the packet's IP header looking for a CIPSO
> > option.  Returns a pointer
> > - * to the start of the CIPSO option on success, NULL if one if not
> > found.
> > + * to the start of the CIPSO option on success, NULL if one is not
> > found.
> >   *
> >   */
> >  unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
> > @@ -1522,9 +1522,11 @@ unsigned char *cipso_v4_optptr(const struct
> > sk_buff *skb)
> >         int optlen;
> >         int taglen;
> > 
> > -       for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen >
> > 0; ) {
> > +       for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen >
> > 1; ) {
> >                 switch (optptr[0]) {
> >                 case IPOPT_CIPSO:
> > +                       if (!optptr[1] || optptr[1] > optlen)
> > +                               return NULL;
> >                         return optptr;
> >                 case IPOPT_END:
> >                         return NULL;
> > @@ -1534,6 +1536,10 @@ unsigned char *cipso_v4_optptr(const struct
> > sk_buff *skb)
> >                 default:
> >                         taglen = optptr[1];
> >                 }
> > +
> > +               if (!taglen || taglen > optlen)
> > +                       break;
> I tend to think that you reach a point where you simply need to trust
> that the stack is doing the right thing and that by the time you hit
> a
> certain point you can safely assume that the packet is well formed,
> but I'm not going to fight about that here.
> 
> Regardless of the above, I don't like how you're doing the option
> length check twice in this code, that looks ugly to me, I think we
> can
> do better.  How about something like this:
> 
>   for (...) {
>     switch(optptr[0]) {
>     case IPOPT_END:
>       return NULL;
>     case IPOPT_NOOP:
>       taglen = 1;
>     default:
>       taglen = optptr[1];
>     }
>     if (taglen == 0 || taglen > optlen)
>       return NULL;
>     if (optptr[0] == IPOPT_CIPSO)
>       return optptr;
>     ....
>   }
> 

You're right, that looks much better. I sent around a new patch.

> > 
> >                 optlen -= taglen;
> >                 optptr += taglen;
> >         }


Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

      parent reply	other threads:[~2018-09-17 23:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 15:11 [PATCH net] net/ipv4: defensive cipso option parsing Stefan Nuernberger
2018-09-17 16:35 ` Paul Moore
2018-09-17 17:46   ` [PATCH v2 " Stefan Nuernberger
2018-09-17 20:31     ` Paul Moore
2018-09-18  2:38     ` David Miller
2018-09-17 18:02   ` Nuernberger, Stefan [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1537207349.7627.32.camel@amazon.de \
    --to=snu@amazon.de \
    --cc=aams@amazon.de \
    --cc=netdev@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=stable@vger.kernel.org \
    --cc=yujuan.qi@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.