Re: [Full-Disclosure] [RHSA-2003:088-01] New kernel 2.2 packages fix vulnerabilities

From: nate (fulldisclosure@aphroland.org)
Date: 03/25/03

  • Next message: Tibor Pittich: "[Full-Disclosure] unreleased php-nuke sql injections"
    From: "nate" <fulldisclosure@aphroland.org>
    To: <full-disclosure@lists.netsys.com>
    Date: Tue, 25 Mar 2003 09:10:17 -0800 (PST)
    

    Etaoin Shrdlu said:

    > Jeeze, they only stopped supporting SunOS a couple of years ago (and I
    > still have the last full set of patches for 4.1.4). End of regular support
    > is not the same as end of life (which happened to solaris 2.4 a while
    > back). Red Hat is out of line (but then I only use Slackware, so what do I
    > care).

    I use debian so..

    but the point I'd like to make is, unlike solaris, end users of redhat
    do have the source(you can get the source to solaris, but last time I
    looked it seemed pretty minimal, maybe just the kernel?? though I didn't
    do a real good job of browsing the CD). You can patch it yourself. I
    was quite pleased when I downloaded linux 2.2.25 to see that it was
    a 6 line patch to kenrel/kmod.c. This is called by CONFIG_KMOD, a
    kernel config option I have NEVER used. I've always hated the kernel
    module auto loader so it's always disabled in my homebrew kenrels(which
    run on all my systems). It is trivial to patch, I'm no developer and
    within a couple minutes I backported the patch to my 2.2.19 trees,
    then I realized I didn't need to in the first place :)

    Granted some users out there may not have the skills to do such
    a feat, but they can hire a consultant to do it for them, or upgrade
    to a newer release of the OS(shameless plug - debian supports sparc too),
    for little or no money. Contrast that to Sun/SGI/HPaq/MS where often
    you do not have the source and are at the complete mercy of the vendor.
    Unless they are a really big customer of the vendor and has influence
    to get stuff done(one of the customers of my former employer had such
    clout with HPaq, could get patches expedited to him somehow).

    to be fair, debian has not announced a updated set of kernel
    packages for this particular bug yet as far as I can tell.

    some bugs may be harder to patch, but this one was simple, I can't
    imagine why the redhat rpm wouldn't build since the patch(at least
    what was in 2.2.25) was platform independant. sounds like a hard
    coded setting within the SRPM itself.

    just for reference, the patch(diff'd against 2.2.19):

    --- kernel/kmod.c Tue Mar 18 14:10:18 2003
    +++ kenrel/kmod.c Tue Mar 18 14:11:40 2003
    @@ -155,12 +155,18 @@
                     atomic_dec(&kmod_concurrent);
                     return -ENOMEM;
             }
    + {
    + int old=current->dumpable;
    + current->dumpable=0; /* block ptrace */

             pid = kernel_thread(exec_modprobe, (void*) module_name, 0);
             if (pid < 0) {
                     printk(KERN_ERR "request_module[%s]: fork failed, errno %d\n",
    module_name, -pid);
                     atomic_dec(&kmod_concurrent);
    + current->dumpable=old;
                     return pid;
    + }
    + current->dumpable=old;
             }

             /* Block everything but SIGKILL/SIGSTOP */

    I built a kernel successfully with the above patch, but have not
    booted it, I expect it to work, but as above, I don't use CONFIG_KMOD
    so I don't have a need to apply the patch to my systems.

    worst case? recompile the kernel and disable CONFIG_KMOD and your
    done(after a reboot), assuming it's turn on in the first place(usually
    is).

    really, not as big of a deal as some would make it out to be, at least
    for me since I was never vulnerable in the first place :)

    having the source is really great sometimes.

    anyone remember the fiasco with redhat and CDE a few years back? maybe
    1997/8.. CDE has a buncha vulnerabilities but redhat could not fix them
    since they didn't have the source, I think after that they decided to
    stop using closed source stuff on their distros. That incident bit
    them pretty hard, CDE was dropped pretty quickly after that. Or maybe
    they had the souce but the license preventing them from distributing
    a fix.

    nate

    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html


  • Next message: Tibor Pittich: "[Full-Disclosure] unreleased php-nuke sql injections"

    Relevant Pages

    • Re: This is [Re:] How to improve the quality of the kernel[?].
      ... The -mm kernel already implements what your proposed PTS would do. ... If patch have no TS ID, ... Thus i can apply for example lguest patches and implement and test new ... How many open source projects use Bugzilla and how many use the Debian BTS? ...
      (Linux-Kernel)
    • Re: [PATCH] new CSA patchset for 2.6.8
      ... Please don't send patches as attachments, and please don't send more than ... one patch per email. ... judging how useful this feature is to Linux implementors and how well this ... > functional kernel. ...
      (Linux-Kernel)
    • Re: Documentation - how to apply patches for various trees
      ... >> explanation of the various kernel trees and how to apply their patches. ... +a patch to the kernel or, more specifically, what base kernel a patch for ... +and what new version the patch will change the source tree into. ...
      (Linux-Kernel)
    • Re: Documentation - how to apply patches for various trees
      ... >> explanation of the various kernel trees and how to apply their patches. ... +a patch to the kernel or, more specifically, what base kernel a patch for ... +kernel source directories it was generated against. ...
      (Linux-Kernel)
    • [PATCH] add EOWNERDEAD and ENOTRECOVERABLE
      ... that uses them yet, I know of two patches in development, ... There is interest in robust mutexes in Linux, ... Even though there are kernel components to the robust mutex ... I know that it is rare for an unused patch to be accepted; ...
      (Linux-Kernel)