Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 31 Jan 2014 20:47:46 +0100
Subject: Re: Linux 3.4+: arbitrary write with CONFIG_X86_X32

>>>>> "SD1" == Solar Designer <> writes:

    SD1> On Fri, Jan 31, 2014 at 07:18:33PM +0100, wrote:
    >> >>>>> "SD0" == Solar Designer <> 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 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, 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?


    >> 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]
    >> [2]

    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 patch or if not yet available the original patch and adapt it
to our kernel. We will run/support 3.12 longer than 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.


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.