linux-kernel - Re: [PATCH] media: usb: ttusb-dec: avoid buffer overflow in ttusb_dec_handle

lists.openwall.net		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 linux-cve-announce 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 <baijiaju1990@...il.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     mchehab@...nel.org, kstewart@...uxfoundation.org,
        tomasbortoli@...il.com, sean@...s.org, allison@...utok.net,
        tglx@...utronix.de, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
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:
>> 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