Vulnerabilities in udev
Agathoklis D. Hatzimanikas
a.hatzim at gmail.com
Mon Apr 27 15:03:34 PDT 2009
On Mon, Apr 27, at 02:52 Bruce Dubbs wrote:
> Mike McCarty wrote:
> > Well, you see there are two exposures involved, the obvious one
> > possible exploit of known vulnerability
> > and the less obvious one
> > replacing working code with with defective code
> > The first exposure is relatively easy to evaluate; the latter is less
> > so, but exists nonetheless. I like to hear that a given patch or other
> > fix has "burnt in" for a while, especially where exposure due to
> > the know vulnerability has low or even nonexistent possibility of
> > exploit.
> > I was hoping to get more information about how to evaluate my exposure.
> Look at the source of the patch. The header says that the changes are from
> upstream. They will be in future versions of the code. To evaluate the
> vulnerability, the header says it fixes CVE-2009-1185 and CVE-2009-1186. Google
> that and you can read all about it.
This is pretty serious.
And for Mike,
LFS is actually teaching administration, so it has the obligation and
the duty to teach the user to follow religiously the recommendations as
far it concerns security problems; in fact I would like to use the
*preach* expression instead of teach, to emphasize how the administrator
should take seriously the security domain.
So while the individual can choose, by looking to the security reports,
not to fix the vulnerabilities in her machine, in LFS we have *no* other
choice than to report them and publish fixes (if available), no matter how
critical they are. We are talking here about practices.
Actually this is a gift (learning good practices) you take for free if
you follow LFS, or a serious Linux or BSD distribution, even for a short
period of time.
This is the strength of the Open Source world and no matter the recent
bloat (mostly in Linux) security is taken seriously to this part of the
More information about the lfs-support