bktr(4) risk?
- From: Jonathan Chen <jon@xxxxxxxxxxx>
- Date: Mon, 9 Oct 2006 17:37:33 -0400
While trying to resurrect meteor(4), I've been looking over the bktr
driver. It seems that the bktr driver implements the METEORSVIDEO ioctl,
which appears to allow userland programs to specify a physical memory
address to which the bktr hardware should dump it's output. At first
glance, this seems like a rather bad idea, as this would allow anyone armed
with the bktr file descriptor to arbitrarily trash any memory, and the bktr
device comes with a friendly default permission of 0444.
The only reason I can think of to use this ioctl would be if you wanted the
image you're capturing to be directly dumped into video memory. This
doesn't seem too useful a task for a video capture card to be doing.
Perhaps we should put a test for write access in there or just eliminate
the ioctl altogether. It should be noted that the meteor driver had this
ioctl ifdef'ed out prior to its removal.
Disclaimer: I don't have access to a bktr myself, nor am I very familiar
with the intricacies of DMA, so someone with the expertise or the hardware
should check my reasoning or test an exploit before panicing.
-Jon
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: bktr(4) risk?
- From: John-Mark Gurney
- Re: bktr(4) risk?
- Prev by Date: man(1) and locale codeset
- Next by Date: Re: bktr(4) risk?
- Previous by thread: man(1) and locale codeset
- Next by thread: Re: bktr(4) risk?
- Index(es):
Relevant Pages
|
