Security patches

Ken Moffat ken at
Tue Aug 16 13:47:06 PDT 2005


 One of the things I've started spending more time on recently is trying
to ensure my systems are patched against known problems. [ Ah, the good
old days when I only had a handful of applications to worry about ].
Most of the packages I'm trying to monitor are not in the LFS book, but
a few of them are.

 First in line is bzip2 with the CAN-2005-0758 vulnerability (same
vulnerability as zgrep - if a user can be persuaded to run bzgrep on a
number of files in an untrusted directory which contain specially
crafted file names, arbitrary commands can be invoked with the
permissions of the user - think sed commands).  AFAIK, there is no
publically-accessible development branch of bzip to monitor for their

 I've picked a patch out of fedora (modified to change the interpreter
to /bin/bash instead of /bin/sh because of bash-specific pattern
replacements) and people who don't read lfs-security can find it at
(watch for line wrap)

 This vulnerability should be low risk for most of us, but I think it's
the sort of thing that ought to be applied.  The question is, what do
other people, particularly LFS editors, think ?  Should there be a
severity threshold, and less critical patches need to be discussed on
this list, or should I just go ahead and commit ?

  Do people think the patches need to be reviewed for apparent
correctness, or is the opinion of one editor that a patch looks
reasonable sufficient ?  ( The first patch agaisnt this vulnerability
that I found was from ubuntu, but although they correctly identified the
need to use /bin/bash I think they went overboard on the backslashes and
made the first part do nothing).

 Is there a tradeoff to be made between patching as soon as we mere
mortals find out about new vulnerabilities (mainstream distros get to
participate on non-disclosure lists, so they can create the patches) and
reviewing what we put into the book ?

 Opinions ?

 das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-dev mailing list