lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 6 May 2020 23:30:22 +0800
From:   Jia-Ju Bai <>
To:     Greg KH <>
Subject: Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in
 ttusb_dec_handle_irq() when DMA failures/attacks occur

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:
> 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

Powered by blists - more mailing lists