Quoting Michael Richards <[EMAIL PROTECTED]> (from Mon, 27 Nov 2006
16:07:56 +0000 (UTC)):
[It's just a panic]
I was so transfixed on Josh stating that the attacker could as well
just mount a filesystem with suid root binaries and how that would be
more useful than a buffer overflow in the filesystem driver. I totally
missed the fact that we were talking about two bugs where the kernel
deliberately called panic() ;).
So in this case I'd agree that the panic() is undesirable, but not
really a security issue.
In the past we have considered remote DOS type attacks to be a security
issue. In this case people discount it saying if the user has physical
access then it's game over anyway. Althought not as serious as privilege
As you said, this is not a remote attack. A local DOS is not nice and
should be fixed if feasible, but is not something we typically give as
high a priority as major security problems.
escalation bugs I would have to say that mounting a user's USB drive
shouldn't allow the system to crash. How about something to force a fsck
before allowing the mount? Would that always catch it?
Maybe you fail to see how large the problem is: no filesystem we have
so far has enough protections for this kind of problems. Doing a fsck
may be a solution for a lot of possible problems in such a case, but
- you don't want to force a fsck of a multi-GB USB harddisk, the
user will run away to another OS until it is finished
- you shift the problem to a FS where we don't have a fsck for
(FAT comes to mind)
Bye,
Alexander.
--
Love -- the last of the serious diseases of childhood.
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
