Hi Furuta-san - This bug is not specific to the 2.6.19 kernel.  The necessary fix was included in 2.6.19.1 and versions prior to that are vulnerable.  Thus RHEL5 is affected.   

This vulnerability could allow a local attacker to modify certain files during a core dump.  According to [1] there are no known exploits of this bug.  So there should be no need to implement a workaround.  However the vulnerability does exist in RHEL5 and so we should include the fix.

I'd also like to receive confirmation from engineering, however I am fairly confident in my findings/analysis.

~dmaley

[1] http://www.securityfocus.com/bid/21591/exploit

> I'd also like to receive confirmation from engineering, however I am fairly
> confident in my findings/analysis.

Certainly the bug exists in RHEL5 -- is that what you're asking for confirmation?

> Certainly the bug exists in RHEL5 -- is that what you're asking for
> confirmation?

yes, but also that there's no apparent risk associated for which we should be providing guidance/workarounds?

I have no idea.

OK then since there's a CVE assigned and the actual risks are unclear I'm adding the "Security" keyword.  If there's something more/else I should do to ensure the security folks are made aware pls let me know.

This issue did not affect the versions of Linux kernel as shipped with Red Hat Enterprise Linux 5 when it was first reported back in 2006 with CVE-2006-6304. However, the issue was introduced last July 2008 with a patch for "[misc] pipe support to /proc/sys/net/core_pattern".

In the do_coredump() function, the flag is only set (to O_EXCL) if mm->dumpable is 2.

fs/exec.c:
        /*
         *      We cannot trust fsuid as being the "true" uid of the
         *      process nor do we know its entire history. We only know it
         *      was tainted so we dump it as root in mode 2.
         */ 
        if (mm->dumpable == 2)          /* Setuid core dump mode */
        {
                flag = O_EXCL;          /* Stop rewrite attacks */
                current->fsuid = 0;     /* Dump root private */
        }
        mm->dumpable = 0;

"And then filp_open follows with "flag" totally ignored."

Note that this issue only matters if dumpable is set to 2. The default is 0.

See man 5 proc:
/proc/sys/fs/suid_dumpable (since Linux 2.6.13)
The value in this file determines whether core dump files are produced for set-user-ID or otherwise protected/tainted binaries. Three different integer values can be specified:
[...]
2 ("suidsafe") Any binary which normally would not be dumped (see "0" above) is dumped readable by root only. This allows the user to remove the core dump file but not to read it. For security reasons core dumps in this mode will not overwrite one another or other files. This mode is appropriate when administrators are attempting to debug problems in a normal environment.

Ensure that suid_dumpable is always set to 0.

So, I'm reviewing this, and while clearly its a good patch to take on priciple, I really don't think the impact of this bug warrants  zstream release. By omitting O_EXCL, we simply inform the the kernel that it shold fail if the attempted file creation already exists.  By not doing that, we simply offer an attacker the opportunity to append data to a core file (by guesssing the file name and creating a very large file (larger than the core), prior to crashing the prcoess whos core will map to that same name.  Potentially irritating, yes, but certainly not serious from a security standpoint.  I get putting it in 5.5, but do we really need to crack open 5.4.z for this?

As discussed last week, we will fix this in 5.4.z.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0046 https://rhn.redhat.com/errata/RHSA-2010-0046.html