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]

Message-ID: <20200506155257.GB3537174@kroah.com>
Date:   Wed, 6 May 2020 17:52:57 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Jia-Ju Bai <baijiaju1990@...il.com>
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 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.

> Thus, it is dangerous that the whole kernel can be attacked via a simple
> malicious device, through some vulnerabilities in the trusted driver.

True, so restrict physical access.  Or use a good iommu if you care
about this :)

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

If you trust a device enough to plug it in, well, you need to trust it
:)

thanks,

greg k-h