[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 31 Jan 2014 20:47:46 +0100
From: rf@...eap.de
To: oss-security@...ts.openwall.com
Subject: Re: Linux 3.4+: arbitrary write with CONFIG_X86_X32
(CVE-2014-0038)
>>>>> "SD1" == Solar Designer <solar@...nwall.com> writes:
SD1> On Fri, Jan 31, 2014 at 07:18:33PM +0100, rf@...eap.de wrote:
>> >>>>> "SD0" == Solar Designer <solar@...nwall.com> writes:
SD0> Even though the issue was easy to patch, I nevertheless find
SD0> this impressively quick for a major distro like Ubuntu, and this
SD0> probably justifies the extra day of embargo.
>>
>> Yup, was good for us too, so we could double-check that the
>> proposed fix from your mail is working OK for others as well,
>> since it hasn't arrived in the kernel.org stable-queue git yet.
SD1> I think there's some confusion here. By "the extra day of
SD1> embargo" I was referring to the second day of the issue being
SD1> known to linux-distros and security@...nel.org, but not made
SD1> public yet. So it's the day right before the oss-security
SD1> posting.
SD1> You're probably referring to the half-day delay between the
SD1> oss-security posting and the upstream commit by Linus.
I'm referring to the following part of your message in [1]:
Would having about 7 days of advance notice (and at most 19 on some
occasions, per list policy) on a small subset of Linux kernel
vulnerabilities be of much help in preparing update packages?
>> By the way, Ubuntu used the longer original patch, which we used
>> [1] in the end as well (saw too late that Linus already committed
>> the shorter one).
SD1> That's curious, but not surprising: I guess Ubuntu was already
SD1> in the process of testing kernels built with the longer patch
SD1> when PaX Team came up with the shorter patch. Since either
SD1> patch was considered good enough and the proposed embargo
SD1> period was very short, it made sense for them not to restart
SD1> the process.
Exactly, same for us in the end.
>> Coming back to our earlier discussion about linux-distros
>> membership [2]: It definitely helped being on the list.
SD1> Do you mean being on oss-security?
Yes.
>> Since the patch was trivial, we didn't suffer a significant time
>> delay compared to other distros. In case of more complicated
>> patches, this could have gotten tough though given the fact that
>> the new builds need a significant amount of testing as well.
>>
>> It would be nice, if we (and others in a similar boat) could get
>> a head-start of at least a couple of days (that's how I
>> understood your question in [2]). Maybe a "second-class citizen"
>> list could complement the linux-distros list with notifications
>> slightly earlier than on oss-security.
SD1> In this case, it was 2 days of advance notice to all on
SD1> linux-distros. I see no point in splitting this further.
Definitely true in this case.
>> [1] https://qlustar.com/news/qsa-0131141-linux-kernel-vulnerabilities
>> [2] http://www.openwall.com/lists/oss-security/2014/01/22/1
SD1> OK, you have demonstrated nicely that you're able to issue
SD1> advisories and updates promptly. Well done!
SD1> However, since you ended up updating your kernel based on which
SD1> fixes went into Ubuntu's, would you do that any quicker if you
SD1> were on linux-distros?
This time I was lucky in that a) Ubuntu was fast, b) the patch was
trivial and c) the patch was identical to the one needed for our kernel.
None of these are guaranteed. Usually I would take the upstream
kernel.org patch or if not yet available the original patch and adapt it
to our kernel. We will run/support 3.12 longer than kernel.org will
provide updates, so at some stage, we need to start porting patches
ourselves. Note that since we're providing Lustre/ZFS support, we have some
restrictions in what kernel versions we use.
SD1> Ubuntu's kernel updates became available only after public
SD1> disclosure anyway. Would you approach fixing this issue in
SD1> your kernels differently if you had advance notice (but no
SD1> access to Ubuntu's work-in-progress on their updates)? Of
SD1> course, you could, by applying one of PaX Team's patches posted
SD1> to linux-distros directly, or:
Yes, see above.
SD1> Given the specialized nature of your distro, I think it'd be
SD1> best for you to disable x32 support until you possibly include
SD1> an x32 userland.
Sure, I know.
SD1> BTW, Ubuntu's advisory text (and thus also yours) is slightly
SD1> wrong:
SD1> <grsecurity> Ubuntu's advisory says the vulnerability is in
SD1> recvmsg. It should say recvmmsg (newer syscall).
Thanks, fixed.
Roland
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
