[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWQT9T8bh6ycpzvt6C_xfce+BuMQe6hP+8JPJE_3OMqJQ@mail.gmail.com>
Date: Wed, 29 Oct 2014 15:24:38 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Dmitry Kasatkin <dmitry.kasatkin@...il.com>
Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
James Morris <jmorris@...ei.org>,
"security@...nel.org" <security@...nel.org>
Subject: Re: [GIT PULL] Fix for Integrity subsystem null pointer deref
On Wed, Oct 29, 2014 at 3:23 PM, Dmitry Kasatkin
<dmitry.kasatkin@...il.com> wrote:
> On 29 October 2014 23:22, Andy Lutomirski <luto@...capital.net> wrote:
>> On Oct 29, 2014 1:20 PM, "Mimi Zohar" <zohar@...ux.vnet.ibm.com> wrote:
>>>
>>> On Wed, 2014-10-29 at 11:51 -0700, Andy Lutomirski wrote:
>>> > On Wed, Oct 29, 2014 at 11:36 AM, Dan Carpenter
>>> > <dan.carpenter@...cle.com> wrote:
>>> > > On Wed, Oct 29, 2014 at 09:23:45AM -0700, Andy Lutomirski wrote:
>>> > >> I have no idea what the semantics are. All I'm saying is that it
>>> > >> looks like the code still accesses memory past the end of the buffer.
>>> > >> The buffer isn't a null pointer, so the symptom is different, but it
>>> > >> may still be a security bug.
>>> > >>
>>> > >> --Andy
>>> > >
>>> > > It only reads one byte into the struct "xattr_data->type" so checking
>>> > > for non-zero is sufficient and the patch is fine.
>>> >
>>> > Indeed. Still... eww. I don't like code that, upon local inspection,
>>> > is apparently wrong, even though it's coincidentally correct due to
>>> > some other far away condition.
>>>
>>> No, the code may be incomplete, but definitely not wrong.
>>
>> I said "apparently wrong" instead of "wrong" for a reason :)
>
> I see there is a long discussion about this patch.
>
> Actually using something like this "if (xattr_value_len <
> sizeof(struct evm_ima_xattr_data))" or using sizeof (struct
> signature_v2_hdr)
> in this function does not give too much.
> xattr value is variable length value and having that statement false
> absolutely does not mean that the value is correct.
> It can be even a random garbage of the correct size.
> This particular function checks the first byte only so the test is good enough.
>
My point is that there's no possible way to tell that only the first
byte is read just by reading the function.
--Andy
> - Dmitry
>
>>
>>>
>>> Mimi
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks,
> Dmitry
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists