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
| ||
|
Message-Id: <750b09b5-f898-fe7f-1e82-1f6c06cc0f58@linux.vnet.ibm.com> Date: Fri, 5 May 2017 19:06:56 +0200 From: Ursula Braun <ubraun@...ux.vnet.ibm.com> To: Jason Gunthorpe <jgunthorpe@...idianresearch.com> Cc: "hch@....de" <hch@....de>, Sagi Grimberg <sagi@...mberg.me>, Bart Van Assche <Bart.VanAssche@...disk.com>, "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org> Subject: Re: net/smc and the RDMA core On 05/04/2017 05:31 PM, Jason Gunthorpe wrote: > On Thu, May 04, 2017 at 03:08:39PM +0200, Ursula Braun wrote: >> >> >> On 05/04/2017 10:48 AM, hch@....de wrote: >>> On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote: >>>> I would also suggest that you stop exposing the DMA MR for remote >>>> access (at least by default) and use a proper reg_mr operations with a >>>> limited lifetime on a properly sized buffer. >>> >>> Yes, exposing the default DMA MR is a _major_ security risk. As soon >>> as SMC is enabled this will mean a remote system has full read/write >>> access to the local systems memory. >>> >>> There ??s a reason why I removed the ib_get_dma_mr function and replaced >>> it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name >>> and a very long comment explaining why, and I'm really disappointed that >>> we got a driver merged that instead of asking on the relevant list on >>> why a change unexpertong a function it needed happened and instead >>> tried the hard way to keep a security vulnerarbility alive. >>> >> Thanks for pointing out these problems. We will address them. > > So, you've created a huge security hole in the kernel, anyone who > loads your smc module is vunerable. > > What are you going to do *RIGHT NOW* to mitigate this? > > Jason We do not see that just loading the smc module causes this issue.The security risk starts with the first connection, that actually uses smc. This is only possible if an AF_SMC socket connection is created while the so-called pnet-table is available and offers a mapping between the used Ethernet interface and RoCE device. Such a mapping has to be configured by a user (via a netlink interface) and, thus, is a conscious decision by that user. Nevertheless, thanks for all the valuable feedback; we take this security risk seriously and addressing it is obviously at the top of our list. We're working on this issue right now, and will post patches as soon as possible. Ursula
Powered by blists - more mailing lists