Messages in this thread | | | Subject | Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur | From | Jia-Ju Bai <> | Date | Thu, 7 May 2020 13:15:22 +0800 |
| |
On 2020/5/7 1:43, Greg KH wrote: > On Thu, May 07, 2020 at 12:48:47AM +0800, Jia-Ju Bai wrote: >> Yes, I agree that this issue is not new, because DMA attacks are old >> problems. >> But I am a little surprised that many current drivers are still vulnerable >> to DMA attacks. > Given that the attack vector is very hard to actually do, that's not > a suprise. > > It's only a very recent thing that Linux drivers have started to work on > "we don't trust the data coming from the hardware" path. Previously we > always trusted that, but did not trust data coming from userspace. So > work on fixing up drivers in this area is always encouraged. > > An example of this would be all of the fuzzing that USB drivers have > been getting with custom loop-back interfaces and the like over the past > year or so. Expanding that to "we don't trust PCI device data" should > be the next step on this, and would help out your area as well.
Okay, I am glad to hear that :) Hardware security for the Linux kernel should receive more attention. Last year some researchers finished an interesting work about fuzzing the inputs from hardware: https://github.com/securesystemslab/periscope
> >>> If you trust a device enough to plug it in, well, you need to trust it >>> :) >> Well, maybe I need to trust all devices in my computer :) >> >> Anyway, thanks a lot for your patient explanation and reply. >> If you have encountered other kinds of DMA-related bugs/vulnerabilities, >> maybe I can help to detect them using my static-analysis tool :) > Did you only find a problem in this one driver? Have you run it on any > more "complex" drivers and gotten any good results showing either that > we are programming defensively in this area, or not? >
At present, I only detect the cases that a DMA value *directly* taints array index, loop condition and important kernel-interface calls (such as request_irq()). In this one driver, I only find two problems that mentioned in this patch. With the kernel configuration "allyesconfig" in my x86_64 machine, I find nearly 200 such problems (intra-procedurally and inter-procedurally) in all the compiled device drivers.
I also find that several drivers check the data from DMA memory, but some of these checks can be bypassed. Here is an example in drivers/scsi/esas2r/esas2r_vda.c:
The function esas2r_read_vda() uses a DMA value "vi": struct atto_ioctl_vda *vi = (struct atto_ioctl_vda *)a->vda_buffer;
Then esas2r_read_vda() calls esas2r_process_vda_ioctl() with vi: esas2r_process_vda_ioctl(a, vi, rq, &sgc);
In esas2r_process_vda_ioctl(), the DMA value "vi->function" is used at many places, such as: if (vi->function >= vercnt) ... if (vi->version > esas2r_vdaioctl_versions[vi->function]) ...
However, when DMA failures or attacks occur, the value of vi->function can be changed at any time. In this case, vi->function can be first smaller than vercnt, and then it can be larger than vercnt when it is used as the array index of esas2r_vdaioctl_versions, causing a buffer-overflow vulnerability.
I also submitted this patch, but no one has replied yet: https://lore.kernel.org/lkml/20200504172412.25985-1-baijiaju1990@gmail.com/
Best wishes, Jia-Ju Bai
| |