Quoting Michael Richards <michael@fastmail.ca> (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