[patch 0/9] 2.6.25.10 -stable review - Kernel

This is a discussion on [patch 0/9] 2.6.25.10 -stable review - Kernel ; Al Viro escreveu: > On Sat, Jul 19, 2008 at 03:13:43PM -0700, Greg KH wrote: > > >> I disagree with this and feel that our current policy of fixing bugs and >> releasing full code is pretty much the ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: [patch 0/9] 2.6.25.10 -stable review

  1. Re: [stable] Linux 2.6.25.10 (resume)

    Al Viro escreveu:
    > On Sat, Jul 19, 2008 at 03:13:43PM -0700, Greg KH wrote:
    >
    >
    >> I disagree with this and feel that our current policy of fixing bugs and
    >> releasing full code is pretty much the same thing as we are doing today,
    >> although I can understand the confusion. How about this rewording of
    >> the sentance instead:
    >>
    >> We prefer to fix and provide an update for the bug as soon as
    >> possible.
    >>
    >> So a simple 1 line change should be enough to stem this kind of argument
    >> in the future, right?
    >>

    >
    > Not quite... OK, here's a story that might serve as a model
    > of all that crap - it certainly runs afoul of a bunch of arguments on
    > all sides of that.
    >

    Ual, crap? :-)

    > We all know that POSIX locks suck by design, in particular where it
    > deals with close(2) semantics. "$FOO is associated with process P having
    > a descriptor refering to opened file F, $FOO disappears when any of such
    > descriptors get removed" is bloody inconvenient in a lot of respects. It
    > also turns out to invite very similar kind of wrong assumptions in all
    > implementation that have to deal with descriptor tables being possibly
    > shared. So far the victims include:
    > * FreeBSD POSIX locks; used to be vulnerable, fixed.
    > * OpenBSD POSIX locks; vulnerable.
    > * Linux POSIX locks and dnotify entries; used to be vulnerable, fixed.
    > Plan9 happily avoids having these turds in the first place and IIRC NetBSD
    > simply doesn't have means for sharing descriptor tables. Should such means
    > appear it would be vulnerable as well. Dnotify is Linux-only, er, entity
    > (as in "non sunt multiplicandam"). I haven't looked at Solaris and I couldn't
    > care less about GNU Turd.
    >
    > In all cases vulnerablities are local, with impact ranging from
    > user-triggered panic to rather unpleasant privelege escalations (e.g.
    > "any user can send an arbitrary signal to arbitrary process" in case of
    > dnotify, etc.)
    >
    > The nature of mistaken assumption is exactly the same in all cases.
    > An object is associated with vnode/dentry/inode/whatnot and since it's
    > destroyed on any close(), it is assumed that we shall be guaranteed that
    > such objects will not be able to outlive the opened file they are associated
    > with or the process creating them. It leads to the following nastiness:
    > A and B share descriptor table.
    > A: fcntl(fd, ...) trying to create such object; it resolves descriptor to
    > opened file, pins it down for the duration of operation and blocks
    > somewhere in course of creating the object.
    > B: close(fd) evicts opened file from descriptor table. It finds no objects
    > to be destroyed.
    > A: completes creation of object, associates it with filesystem object and
    > releases the temporary hold it had on opened file.
    >
    > At that point we have an obvious leak and slightly less obvious attack vector.
    > If no other descriptors in the descriptor table of A and B used to refer to
    > the same file, the object will not be destroyed since there will be nothing
    > that could decide to destroy it. Unfortunately, it's worse than just a leak.
    > These objects are supposed to be destroyed before the end of life of opened
    > file. As the result, nobody bothers to have them affect refcounts on the
    > file/vnode/dentry/inode/whatever. That's perfectly fine - the proper fix is
    > to have fcntl() verify that descriptor still resolves to the same file before
    > completing its work and destroy the object if it doesn't. You don't need to
    > play with refcounts for that. However, without that fix we have a leak that
    > leads to more than just an undead object - it's an undead object containing
    > references to filesystem object that might be reused and to task_struct/proc/
    > whatever you call it, again with the possibility of reuse.
    >
    > Getting from that point to the attack is a matter of simple (really simple)
    > RTFS. Details obviously depend on what the kernel in question is doing to
    > these objects, but with that kind of broken assertions it's really not hard
    > to come up with exploitable holes.
    >
    > Now, let us look at the history:
    > * POSIX locks support predates shared descriptor tables; the holes
    > in question opened as soon as clone(2)/rfork(2) had been merged into a kernel
    > and grown support for shared descriptor tables. For Linux it's 1.3.22 (Sep
    > 1995), for OpenBSD it's a bit before 2.0 (Jan 1996) for FreeBSD - 2.2 (Feb
    > 1996, from OpenBSD).
    > * In 2002 dnotify had grown the same semantics (Linux-only thing,
    > 2.5.15, soon backported to 2.4.19). Same kind of race.
    > * In 2003 FreeBSD folks had found and fixed their instance of that bug;
    > commit message:
    > "Avoid file lock leakage when linuxthreads port or rfork is used:
    > - Mark the process leader as having an advisory lock
    > - Check if process leader is marked as having advisory lock when
    > closing file
    > - Check that file is still open after lock has been obtained
    > - Don't allow file descriptor table sharing between processes
    > with different leaders"
    > "Check that file is still open" bit refers to that race. I have no idea
    > whether they'd realized that what they'd closed had been locally exploitable
    > or not.
    > * In 2005 Peter Staubach had noticed the Linux analog of that sucker.
    > The fix had been along the same lines as FreeBSD one, but in case of Linux
    > we had extra fun with SMP ordering. Peter had missed that and his patch
    > left a hard to hit remnant of the race. His commit message is rather long;
    > it starts with
    > [PATCH] stale POSIX lock handling
    >
    > I believe that there is a problem with the handling of POSIX locks, which
    > the attached patch should address.
    >
    > The problem appears to be a race between fcntl(2) and close(2). A
    > multithreaded application could close a file descriptor at the same time as
    > it is trying to acquire a lock using the same file descriptor. I would
    > suggest that that multithreaded application is not providing the proper
    > synchronization for itself, but the OS should still behave correctly.
    > ...
    > I'm 100% sure that in this case the vulnerability had _not_ been realized.
    > Bogus behaviour had been noticed and (mostly) fixed, but implications had
    > been missed, along with the fact that the same scenario had played out in
    > dnotify.
    >

    That's common... We know that will occur from time to time and we are
    not discussing about that... Just about already known security issues
    being silently fixed without any mention.
    > * This April I'd caught dnotify hole during code audit. The fix
    > had been trivial enough and seeing that impact had been fairly nasty (any
    > user could send any signal to any process, among other things) I'd decided
    > to play along with "proper mechanisms". Meaning vendor-sec. _Bad_ error
    > in judgement; the damn thing had not improved since I'd unsubscribed from
    > that abortion. A trivial patch, obviously local to one function and obviously
    > not modifying behaviour other than in case when existing tree would've screwed
    > itself. Not affecting any headers. Not affecting any data structures.
    > _Obviously_ not affecting any 3rd-party code - not even on binary level.
    > IOW, as safe as it ever gets.
    > Alas. The usual ****e had played out and we had a *MONTH-LONG*
    > embargo. I would like to use this opportunity to offer a whole-hearted
    > "**** you" to that lovely practice and to vendor-sec in general.
    >

    huahuahuahuahuhuahuahu, tks for share your felling about that... Maybe
    the wrong people are dealing with that... What do you think?
    > * Very soon after writing the first version of a fix I started
    > wondering if POSIX locks had the same hole - the same kind of semantics
    > had invited the same kind of race there (eviction of dnotify entries and
    > eviction of POSIX locks are called in the same place in close(2)). Current
    > tree appeared to be OK, checking the history had shown Peter's patch.
    > A bit after that I'd noticed insufficient locking in dnotify patch, fixed
    > that. Checking for similar problems in POSIX locks counterpart of that crap
    > had found the SMP ordering bug that remained there.
    > * 2.6 -> 2.4 backport had uncovered another interesting thing -
    > Peter's patch did _not_ make it to 2.4 3 years ago.
    > * Checking OpenBSD (only now - I didn't get around to that back in
    > April) shows that the same hole is alive and well there.
    >
    > Note that
    > * OpenBSD folks hadn't picked the fix from FreeBSD ones, even though
    > the FreeBSD version had been derived from OpenBSD one. Why? At a guess, the
    > commit message had been less than noticable. Feel free to toss yourself off
    > screaming "coverup" if you are so inclined; I don't swing that way...
    >

    I ever used this word... I know others did anyway.
    > * Initial Linux fix _definitely_ had missed security implications
    > *and* realization that somebody else might suffer from the same problem.
    > FVO "somebody" including Linux itself, not to mention *BSD.
    >

    That's the main problem of 'hidden' security bugs... Hidden here must be
    understood as: normal bugs = security bugs
    > * Even when the problem had been realized for what it had been in
    > Linux, *BSD potential issues hadn't registered. Again, the same wunch
    > of bankers is welcome to scream "coverup", but in this case we even have
    > the bleeding CVEs.
    > * CVEs or no CVEs, OpenBSD folks hadn't picked that one.
    >

    Yeah, they don't pay much attention to other projects I they should...
    That's why I always talk about 'copy and paste security bugs' as a real
    problem in open-source projects... Because the original code may be
    fixed and the 'copied' one not
    > * Going to vendor-sec is a mistake I won't repeat any time soon and
    > I would strongly recommend everybody else to stay the hell away from that
    > morass. It creates inexcusable delays, bounds you to confidentiality and,
    >

    Interesting... every people involved in this discussion told us to
    change our behaviour and try to improve things instead of be against
    it... Why not change people involved in the vendor-sec in some way? I
    have no idea who are there, but I'm sure it can be improved since I
    already worked with many vendors to coordinate vuln-disclousure and had
    no problems.

    I'm sure the vendors involved are caring about 'marketing' and things
    like that, that's why there is a delay... They need to learn from others
    mistakes, like Microsoft. The company now really knows how to deal with
    security problems.
    > let's face it, happens to be the prime infiltration target for zero-day
    > exploit traders. In _this_ case exploit had been local-only. Anything more
    > interesting...
    >

    That's true. Mainly because it takes longer to have a fix... I agree
    with the fix asap idea, just don't agree with 'change the message in the
    patch to not apper to be a security bug been fixed'.
    > So where does that leave us? Bugger if I know... FWIW, I would rather see
    > implications thought about *and* mentioned in the changelogs. OTOH, the
    > above shows the real-world cases when breakage hadn't even been realized to
    > be security-significant.

    We ever said it's different otherwise...
    > Obviously broken behaviour (leak, for example)
    > gets spotted and fixed. Fix looks obviously sane, bug it deals with -
    > obviously real and worth fixing, so into a tree it goes... IOW, one _can't_
    > rely on having patches that close security holes marked as such.

    Sometimes no one will figure out that patch closed a security issue...
    We are talking in this thread about patches that are well-known to fix
    security holes... As the bugzilla explicitly says about a security
    problem and in the commit nothing mention that.
    > For that
    > the authors have to notice that themselves in the first place. OTTH, nothing
    > is going to convince the target audience of grsec, er, gentlemen that we are
    > not a massive conspiracy anyway, the tinfoil brigade being what it is...
    >


    There is no target audience involved here... There is no 'marketing' or
    'media circus'... It's just a try to improve things.


    cya,


    Rodrigo (BSDaemon).


    PS: Just my personal thoughts, not related to the company that I work for.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [stable] Linux 2.6.25.10 (resume)

    On Mon, Jul 21, 2008 at 09:48:13PM -0300, Rodrigo Rubira Branco (BSDaemon) wrote:
    > Alan Cox escreveu:
    >>> @@ -1,7 +1,7 @@
    >>> -Linux kernel developers take security very seriously. As such, we'd
    >>> -like to know when a security bug is found so that it can be fixed and
    >>> -disclosed as quickly as possible. Please report security bugs to the
    >>> -Linux kernel security team.
    >>> +Linux kernel developers take security very seriously, in exactly the
    >>> +same way we do with any other bugs. As such, we'd like to know when +a
    >>> security bug is found so that it can be fixed as soon as possible.
    >>> +Please report security bugs to the Linux kernel security team.
    >>>

    >>
    >> NAK this. If the fix is not clear and the bug not too serious it is better
    >> to disclose it than fail to fix it. The security team does not usually fix
    >> the
    >> bugs, the experts in the various bits of code do.
    >>

    > ACK Changed the sentence. Tks.
    >
    >>> -Any exploit code is very helpful and will not be released without
    >>> -consent from the reporter unless it has already been made public.
    >>> +Any exploit code is very helpful and will not be released.
    >>>

    >>
    >> NAK this too. If someone releases an exploit publically or it leaks we
    >> want to be able to freely share it too. Your proposal would mean any but
    >> those dumb enough to agree to this could share it. That is why the unless
    >> made
    >> public is part of every generic NDA document on the planet.
    >>

    > Agreed. Changed the sentence. Tks.
    >> The rest needs Linus to return from holiday for discussion and that'll
    >> be a week or two. In the meantime you might want to define "disclose" as
    >> I don't think we all agree on what it means as you've not defined who is
    >> and
    >> isn't the linux security team and/or its helpers.

    > Cool.


    > --- SecurityBugs.orig 2008-07-16 23:46:09.000000000 -0300
    > +++ SecurityBugs 2008-07-21 07:28:01.000000000 -0300
    > @@ -1,7 +1,9 @@
    > -Linux kernel developers take security very seriously. As such, we'd
    > -like to know when a security bug is found so that it can be fixed and
    > -disclosed as quickly as possible. Please report security bugs to the
    > -Linux kernel security team.
    > +Linux kernel developers take security very seriously, in exactly the
    > +same way we do with any other bugs. As such, we'd like to know when
    > +a security bug is found so that it can be fixed as soon as possible by
    > +the experts in this portion of the kernel code.
    > +
    > +Please report security bugs to the Linux kernel security team.


    You have trailing spaces in your patch, please run all patches through
    scripts/checkpatch.pl to catch stuff like this.

    > @@ -14,23 +16,26 @@
    > As it is with any bug, the more information provided the easier it
    > will be to diagnose and fix. Please review the procedure outlined in
    > REPORTING-BUGS if you are unclear about what information is helpful.
    > -Any exploit code is very helpful and will not be released without
    > -consent from the reporter unless it has already been made public.
    > +Any exploit code is very helpful and will not be released by our team
    > +unless already made public. The exploit code may be shared with third
    > +parties to facilitate a fix or to verify the vulnerability.


    Your two changed sentances are contradictory.
    What is wrong with the original wording?

    > 2) Disclosure
    >
    > The goal of the Linux kernel security team is to work with the
    > bug submitter to bug resolution as well as disclosure. We prefer
    > -to fully disclose the bug as soon as possible. It is reasonable to
    > +to not disclose the bug, since we believe any kind of bug deserves the
    > +same attention and will be quickly patched. It is reasonable to


    No, again, you are using the word "disclose" in an odd way here.

    Of course the bug is "disclosed" in that it is made public, "here's a
    fix for foo breaking".

    So this wording change is not right.

    > delay disclosure when the bug or the fix is not yet fully understood,
    > the solution is not well-tested or for vendor coordination. However, we
    > expect these delays to be short, measurable in days, not weeks or months.
    > A disclosure date is negotiated by the security team working with the
    > -bug submitter as well as vendors. However, the kernel security team
    > -holds the final say when setting a disclosure date. The timeframe for
    > -disclosure is from immediate (esp. if it's already publically known)
    > -to a few weeks. As a basic default policy, we expect report date to
    > -disclosure date to be on the order of 7 days.
    > +bug submitter as well as vendors if the submitter wants to disclose.


    Again, trailing spaces.

    What was wrong with the original wording?

    thanks,

    greg k-h
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [stable] Linux 2.6.25.10 (resume)

    On 22 Jul 2008 at 21:27, Greg KH wrote:

    > > 2) Disclosure
    > >
    > > The goal of the Linux kernel security team is to work with the
    > > bug submitter to bug resolution as well as disclosure. We prefer
    > > -to fully disclose the bug as soon as possible. It is reasonable to
    > > +to not disclose the bug, since we believe any kind of bug deserves the
    > > +same attention and will be quickly patched. It is reasonable to

    >
    > No, again, you are using the word "disclose" in an odd way here.
    >
    > Of course the bug is "disclosed" in that it is made public, "here's a
    > fix for foo breaking".


    it's apparently not true when foo = "kernel's security model", hence the
    suggested change to reflect reality.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [stable] Linux 2.6.25.10 (resume)

    On Wed, 23 Jul 2008, pageexec@freemail.hu wrote:
    > On 22 Jul 2008 at 21:27, Greg KH wrote:
    > > > 2) Disclosure
    > > >
    > > > The goal of the Linux kernel security team is to work with the
    > > > bug submitter to bug resolution as well as disclosure. We prefer
    > > > -to fully disclose the bug as soon as possible. It is reasonable to
    > > > +to not disclose the bug, since we believe any kind of bug deserves the
    > > > +same attention and will be quickly patched. It is reasonable to

    > >
    > > No, again, you are using the word "disclose" in an odd way here.
    > >
    > > Of course the bug is "disclosed" in that it is made public, "here's a
    > > fix for foo breaking".

    >
    > it's apparently not true when foo = "kernel's security model", hence the
    > suggested change to reflect reality.


    I heavily suggest using something else than "disclose".

    For the security community, "disclose" doesn't mean you have the source code
    for the buggy code and the source code for the fix. It means you have the
    information that it is a "foo = kernel's security model" bug, and a
    description of the consequences of the bug for foo (the security model).

    This is NOT what "disclose" means for the Linux kernel, right now. Here,
    "disclose" means "you know there is a bug, you have the code, you have the
    bug fix". But you don't know that "foo = kernel's security bug", or the
    consequences of the bug for the security model.

    So just use another word, or properly qualify WHAT is going to be disclosed,
    (and in this case, WHAT is not going to be *usually* disclosed).

    --
    "One disk to rule them all, One disk to find them. One disk to bring
    them all and in the darkness grind them. In the Land of Redmond
    where the shadows lie." -- The Silicon Valley Tarot
    Henrique Holschuh
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [stable] Linux 2.6.25.10 (resume)

    On 23 Jul 2008 at 11:31, Henrique de Moraes Holschuh wrote:

    > On Wed, 23 Jul 2008, pageexec@freemail.hu wrote:
    > > it's apparently not true when foo = "kernel's security model", hence the
    > > suggested change to reflect reality.

    >
    > I heavily suggest using something else than "disclose".
    >
    > For the security community, "disclose" doesn't mean you have the source code
    > for the buggy code and the source code for the fix. It means you have the
    > information that it is a "foo = kernel's security model" bug, and a
    > description of the consequences of the bug for foo (the security model).
    >
    > This is NOT what "disclose" means for the Linux kernel, right now. Here,
    > "disclose" means "you know there is a bug, you have the code, you have the
    > bug fix". But you don't know that "foo = kernel's security bug", or the
    > consequences of the bug for the security model.


    i think you misunderstood the whole thread here . we were explicitly
    talking about bugs where the kernel devs *knew* they were fixing one
    with an impact on security yet they chose not to say so.

    determining whether a bug is a security one is a whole different kettle
    of fish, that was not the topic here at all.

    IOW, Documentation/SecurityBugs talks about bugs where the security impact
    is known, not about bugs in general where such determination has yet to be
    done.

    > So just use another word, or properly qualify WHAT is going to be disclosed,
    > (and in this case, WHAT is not going to be *usually* disclosed).



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2