Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle_irq() when DMA failures/attacks occur

[Jia-Ju Bai <baijiaju1990@gmail.com>]

On 2020/5/6 19:07, Greg KH wrote:
> On Wed, May 06, 2020 at 06:13:01PM +0800, Jia-Ju Bai wrote:
>> I have never modified DMA memory in the real world, but an attacker can use
>> a malicious device to do this.
>> There is a video that shows how to use the Inception tool to perform DMA
>> attacks and login in the Windows OS without password:
>> https://www.youtube.com/watch?v=HDhpy7RpUjM
> If you have control over the hardware, and can write to any DMA memory,
> again, there's almost nothing a kernel can do to protect from that.

I think that each device can only access its own DMA memory, instead of 
any DMA memory for other hardware devices.
Thus, it is dangerous that the whole kernel can be attacked via a simple 
malicious device, through some vulnerabilities in the trusted driver.

A feasible example is that, the attacker inserts a malicious device via 
PCI-E bus in a locked computer, when the owner of this computer leaves. 
The attacker modifies the DMA memory of this malicious device, to 
exploit the vulnerabilities in the trusted driver and steal key data 
from the computer.
I think this is possible, because many buses (such PCI-E bus) support 
hot plugging now.
Thus, to protect the kernel from such DMA attacks, these vulnerabilities 
in the trusted driver had better be fixed.

Besides, I think that a safe way is to only store data in DMA memory, 
and this data is only passed to userspace and hardware, instead of 
tainting kernel data...

>> Besides, not related to this patch, some drivers use DMA to send/receive
>> data (such as the URB used in USB drivers and ring descriptors used in
>> network drivers). In this case, if the data is malicious and used as an
>> array index through DMA, security problems may occur.
>>
>> In my opinion, similar to the data from userspace, the data from hardware
>> may be also malicious and should be checked.
>>
>> Maybe we could discuss this issue with DMA driver developers?
> Sure, but I think that's outside the scope of this tiny patch :)

Okay, in the discussion e-mail, I will introduce my opinion and give 
several possible DMA issues that I found, thanks :)


Best wishes,
Jia-Ju Bai