UFS Bug: FreeBSD 6.1/6.2/7.0: MOKB-08-11-2006, CVE-2006-5824,
kris at obsecurity.org
Sun Nov 26 00:05:34 PST 2006
On Sat, Nov 25, 2006 at 01:20:33PM +0100, O. Hartmann wrote:
> Scott Long wrote:
> > Kevin Oberman wrote:
> >>> Date: Fri, 24 Nov 2006 15:58:39 -0700
> >>> From: Scott Long <scottl at samsco.org>
> >>> Sender: owner-freebsd-stable at freebsd.org
> >>> David Malone wrote:
> >>>>> These two bugs are shown for FreeBSD only and I guess, Solaris and
> >>>>> other BSDs still use UFS. Are they more robust against this
> >>>>> exploit or type of exploit?
> >>>> I don't know of a concerted effort by anyone to improve UFS in this
> >>>> way. I would guess that the odd bug would have been resolved, but
> >>>> no large scale work.
> >>>> David.
> >>> Another thing to keep in mind is that filesystem mounting is only
> >>> available to the super-user. If a feature came along such as
> >>> automatically mounting USB drives, these bugs would indeed be critical.
> >>> But for now, they are not.
> >> Not on the base system, but Gnome 2.16 with hald running will mount a
> >> removable device automatically. The standard configuration of Gnome runs
> >> hald. Allowing user mounts of removable media is even formalized by the
> >> addition of /media to hier(7). I'm not sure this should simply be
> >> treated as not being significant.
> > Would it be possible to restrict Gnome to only auto-mounting msdos and
> > cd9660 filesystems?
> > Scott
> > _______________________________________________
> > freebsd-stable at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org"
> Sorry, if my question may sound heretic, but wouldn't it be more
> sophisticated solving the problem instead of disabling everything what
> could trigger the bug?
It's been explained to you why "solving the problem" (i.e. adapting
UFS so that no combination of corrupted filesystem data can cause a
panic) is, in all practical senses, probably impossible.
To recap, it would require fundamentally redesigning the UFS code to
perform input validation before using any on-disk data, and adding
some kind of backout and recovery strategies for when bad data is
detected. Apart from the significant additional complexity, this may
have an unacceptable runtime performance penalty.
I hope the status of this issue is clear now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20061126/1d7d38ba/attachment.pgp
More information about the freebsd-stable