On Wed, Aug 06, 2003 at 09:51:39PM +1000, eodyna wrote:
> Hi all,
> 
> Im kinda new to FreeBSD (running 4.5 RELEASE) and Im a
> bit confused. Im hoping someone can help me understand
> what I am doing incorrectly, or point me in a
> direction where I can understand what is happening. As
> you are all aware a security advisory was released
> about realpath.
> 
> I have followed the instructions.
> downloaded the patch. verified it.
> ran patch < path to patch

Did the patch apply cleanly? If there are any .rej files in the
vicinity, then they didn't

> built KERNCONF
> installed KERNCONF

The kernel is beside the point here: the bug is in the libc shared
library.  As instructed you need to rebuild the world and reinstall.
Not just the kernel: viz

    # cd /usr/src
    # make buildworld buildkernel KERNCONF=foo
    # make installkernel KERNCONF=foo
    # shutdown -r now

    [ Interrupt the boot process during the 10 second countdown by
    pressing any key (other than return) to get to the boot loader
    prompt.]

    > boot -s
    [...various output. Hit return when prompted for the shell to use...]
    # fsck -p
    # swapon -a
    # mount -a
    # cd /usr/src
    # make installworld
    # mergemaster
    # exit

After which the system will continue booting to full multi-user mode.
 
> then i went and checked the UPDATING, the realpath.c
> file and the newvers.sh file. According to the email
> these files were meant to be corrected.
> 
> The timestamp on the UPDATING and newvers.sh have not
> changed. and the realpath.c file indicates that it is
> version 1.9 2000/01/27 instead of 1.9.8.1 as indicated
> by the advisory.
> 
> Have I done something wrong? or missed the point? I
> know i dont really understand it. If someone can
> explain it to me or point me in the right direction it
> would be very much appreciated.

OK.  The patches
(ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:08/realpath.patch)
mentioned in the advisory
(ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-03:08.realpath.asc)
won't alter the UPDATING or newvers.sh files -- as those are
essentially documentation and don't have any effect of the resulting
functionality of the system, that's nothing to worry about.  The patch
only affects the realpath.c file, and in that case, it doesn't alter
the version number at the top of the file -- mostly because the patch
is designed to apply to files from a range of different code branches
and hence different version numbers.

In fact, the patch consists in it's entirety of a two line change to
the realpath.c file:


    /tmp:% less realpath.patch 
    Index: lib/libc/stdlib/realpath.c
    ===================================================================
    RCS file: /home/ncvs/src/lib/libc/stdlib/realpath.c,v
    retrieving revision 1.9
    diff -c -c -r1.9 realpath.c
    *** lib/libc/stdlib/realpath.c  27 Jan 2000 23:06:50 -0000      1.9
    --- lib/libc/stdlib/realpath.c  3 Aug 2003 17:21:20 -0000
    ***************
    *** 138,144 ****
                    rootd = 0;
      
            if (*wbuf) {
    !               if (strlen(resolved) + strlen(wbuf) + rootd + 1 > MAXPATHLEN) {
                            errno = ENAMETOOLONG;
                            goto err1;
                    }
    --- 138,145 ----
                    rootd = 0;
      
            if (*wbuf) {
    !               if (strlen(resolved) + strlen(wbuf) + (1-rootd) + 1 >
    !                   MAXPATHLEN) {
                            errno = ENAMETOOLONG;
                            goto err1;
                    }
    

So, unless that patch was rejected, or you have not managed to
recompile and re-install everything, then you will have secured your
system against attack via any dynamically linked program that calls
realpath(1).  As the advisory says, you do need to check for
statically linked programs that use realpath(1). There are none in the
base system, so it's a case of hunting for statically linked programs
installed via ports and re-installing those.

Other than by applying the patch manually as you have done, you could
have used cvsup(1) to update to the latest sources for whatever branch
you prefer.  Even though the security branches before 4.7-RELEASE are
no longer officially supported, patches were applied to them.  In that
case, you would see the updated version numbers on the various files
mentioned.

Note too that 4.5-RELEASE is itself no longer supported and fairly
long in the tooth.  If the system is security critical then you would
be well advised to upgrade it to 4.8-RELEASE-pX as soon as may be:
mostly because you'll need to be able to update ports to counter any
security holes there, and it's not guarranteed that the latest
revisions of the ports system will actually work with older systems.

        Cheers,

        Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to