Re: RSI.0008.08-18-98.ALL.RPC_PCNFSD

From: Brian Martin (bmartinat_private)
Date: Wed Aug 19 1998 - 03:20:23 PDT

  • Next message: Robert Ståhlbrand: "Serious bug in Cisco PIX"

    > ---------- Forwarded message ----------
    > From: Scott Stone <sstoneat_private>
    >
    > > Announced:     July 14, 1998
    > > Report code:   RSI.0008.08-18-98.ALL.RPC_PCNFSD
    > > Vendor status: IBM contacted on August 3, 1998
    > >                Hewlett Packard contacted on August 3, 1998
    > >                Sun Microsystems contacted on August 3, 1998
    > >                Slackware contacted on August 3, 1998
    > > Patch status:  Linux and AIX patch information is provided below
    > > Platforms:     Vulnerable:
    > >
    > >                AIX: 4.0, 4.1, 4.2, 4.3
    > >                HP-UX: 7.x, 8.x, 9.x, 10.x, 11.x
    > >                SunOS: 4.1.3, 4.1.4
    > >                Solaris: 2.3, 2.4, 2.5, 2.5.1, 2.6
    > >                Redhat Linux: 4.0, 4.1, 4.2, 5.0, 5.1
    > >                Slackware Linux: 3.0, 3.1, 3.2, 3.3, 3.4, 3.5
    > >                OSF: 3.2
    >
    >
    > OK, TurboLinux 2.0 is NOT vulnerable, and neither is Redhat 5.1 despite
    > what it says up there.  Why?  Because neither TL nor RH 5.1 even include
    > rpc.pcnfsd (checked by querying every RPM package in both distributions,
    > grepping for 'pcnfs' -- no matches).
    
    Did you look carefully on sunsite?
    
    /pub/Linux/system/network/sunacm/Other/pcnfsd/pcnsfd-140.tar.gz
    
    Notice there is a typo there. "pcnsfd"
    
    > If the intent was to say that the Linux version of rpc.pcnfsd (and the
    > AIX version, i suppose) have this vulnerability, then please don't go
    > naming distributions that don't include it, since it's not the
    
    TurboLinux (and other Linux distributions) were not included because they
    were not tested, and we made no assumptions that they would be vulnerable.
    It was NOT our intent to say "linux in general" was vulnerable.
    
    Reporting that 5.1 itself was vulnerable was a slight error on our part.
    It should have been noted that if the package was added, that the current
    distribution of PCNFSD was vulnerable, and that it would most likely
    compromise the system.
    
    You will also note that OSF was not warned of this problem in advance. The
    reason for that is the lack of access to an OSF machine to test it on.
    Unfortunately we obtained access hours before this advisory went out.
    Testing continued until shortly before the advisory went out, so Digital
    was warned directly, but a bit after other vendors.
    
    > responsibility of the distribution vendor to fix a package that's not part
    > of the distribution.
    
    It is partially vendor responsibility to fix the current distribution as
    well as make their users aware. After contacting both Redhat and Debian
    about this information, it was very disconcerting to see they were
    unwilling to work with us on patching the problem. Both contacts expressed
    a "give me info, screw the rest of the world" attitude which we felt was
    not the best course of action. Their lack of cooperation could have
    eliminated the RH 5.1 issue, as well as guarantee that our patch would be
    effective for all distributions. Instead, we ended up working with Mr.
    Volkerding of the Slackware team who was extremely helpful and very
    concerned about this problem.
    
    > Was notification sent to the author/maintainer(s) of rpc.pcnfsd?
    
    >From the README file in linux_pcnfsd2.tgz located on sunsite.unc.edu, the
    current maintainer or POC is:
    
    Alexander Bezprozvanny (aka BEZ)
    PARSYTEC-Petersburg Ltd.                         E-Mail:   bezat_private
    
    Mail to that address bounced.
    
    In the file pcnfsd.c contained in the pcnsfd-140.tar.gz archive located on
    sunsite, there is no mention of the maintainer of the package.
    
    -
    
    That said, I assure you that RSI continues to try to "do the right thing".
    No matter what course of action we take with a multi-vendor bug, someone
    will not be happy with us. That in mind, we try to please as many people
    as possible and then move on.
    
    
    Brian Martin
    RSI
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:13:02 PDT