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 00:48:47 +0800 |
| |
On 2020/5/6 23:52, Greg KH wrote: > On Wed, May 06, 2020 at 11:30:22PM +0800, Jia-Ju Bai wrote: >> >> 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. > That's not true at all for all systems that Linux runs on.
I am not sure to understand this. For example, a driver requests DMA memory with "len" size by using: mem = dma_alloc_coherent(..., len, ...); I think that the driver can only access DMA memory between "mem" and "mem + len", is it true? Can the driver access other DMA memory using some code like "mem + len * 10"?
> >> 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. > This is a semi-well-known issue. It's been described in the past > regarding thunderbolt devices, and odds are, more people will run across > it again in the future and also complain about it. > > The best solution is to solve this at the bus level, preventing > different devices access to other memory areas. > > And providing physical access control to systems that you care about > this type of attack for. > > Again, this isn't a new thing, but the ability for us to do much about > it depends on the specific hardware control, and how we set defaults up.
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.
> > 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 :)
Best wishes, Jia-Ju Bai
| |