All of lore.kernel.org
 help / color / mirror / Atom feed
From: Solar Designer <solar@openwall.com>
To: David Wagner <daw-usenet@taverner.cs.berkeley.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] getsockopt() early argument sanity checking
Date: Mon, 21 Aug 2006 12:24:08 +0400	[thread overview]
Message-ID: <20060821082408.GA24442@openwall.com> (raw)
In-Reply-To: <ecb7k6$grh$1@taverner.cs.berkeley.edu>

(I realize that the patch has been rejected and this message is in no
way meant to affect that decision.)

On Mon, Aug 21, 2006 at 03:00:22AM +0000, David Wagner wrote:
> Solar Designer  wrote:
> >The patch makes getsockopt(2) sanity-check the value pointed to by
> >the optlen argument early on.  This is a security hardening measure
> >intended to prevent exploitation of certain potential vulnerabilities in
> >socket type specific getsockopt() code on UP systems.
> 
> This looks broken to me.  It has a TOCTTOU (time-of-check-to-time-of-use)

Yes it does, using Matt Bishop's classification.

> vulnerability (i.e., race condition): you read the length value twice,
> and assume that you will get the same value both times.  That assumption
> is not valid.

I don't assume that.  I realize that there's the race condition on SMP
and, as pointed out by Andi Kleen, in many cases also on UP systems.
That's why I had the XXX comment in there from the very beginning.

This added check is not supposed to be relied upon; rather, it is a
hardening measure in case we miss a bug in underlying *getsockopt()
functions.

> It looks like it will be easy to bypass this check.

It depends.  You might have missed this description of a special case
where it does not appear to be possible to bypass the check:

	http://lkml.org/lkml/2006/8/20/148

Yes, the patch is highly controversial and I mostly agree with its
opponents (I had much of the same thoughts myself, except for DaveM's
concern that *optlen might be uninitialized or negative on purpose),
yet I am going to keep it in -ow.

BTW, I had previously submitted a very similar check to do_sysctl(),
also with an XXX comment, which got in a few years back.

I won't be surprised if one of these checks saves a system from a
compromise one day.  This world is not perfect - neither the rest of the
Linux kernel code nor vulnerability exploit programs are perfect.

Alexander

P.S. Please CC me on your replies.

  reply	other threads:[~2006-08-21  8:28 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-19 23:05 [PATCH] getsockopt() early argument sanity checking Solar Designer
2006-08-19 23:48 ` Willy Tarreau
2006-08-20  0:05   ` Michael Buesch
2006-08-20  0:43     ` Willy Tarreau
2006-08-20 19:44       ` David Miller
2006-08-20 20:35         ` Willy Tarreau
2006-08-20 21:12           ` Arjan van de Ven
2006-08-21 12:09       ` Eugene Teo
2006-08-20  8:34 ` Andi Kleen
2006-08-20 10:15   ` Willy Tarreau
2006-08-20 10:50     ` YOSHIFUJI Hideaki / 吉藤英明
2006-08-20 19:46     ` David Miller
2006-08-20 16:16   ` Solar Designer
2006-08-20 16:30     ` Arjan van de Ven
2006-08-20 19:47       ` David Miller
2006-08-20 18:38     ` Andi Kleen
2006-08-20 19:45       ` Solar Designer
2006-08-20 19:45   ` David Miller
2006-08-20 18:15 ` Alan Cox
2006-08-21  3:00 ` David Wagner
2006-08-21  8:24   ` Solar Designer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-08-20 18:57 Manfred Spraul

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=20060821082408.GA24442@openwall.com \
    --to=solar@openwall.com \
    --cc=daw-usenet@taverner.cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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.