linux-kernel - Re: [PATCH 4.19 14/48] mtd: properly check all write ioctls for permissions

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:   Mon, 10 Aug 2020 20:40:47 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     Pavel Machek <pavel@...x.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        stable <stable@...nel.org>
Subject: Re: [PATCH 4.19 14/48] mtd: properly check all write ioctls for
 permissions

----- Ursprüngliche Mail -----
> Von: "Pavel Machek" <pavel@...x.de>
>> When doing a "write" ioctl call, properly check that we have permissions
>> to do so before copying anything from userspace or anything else so we
>> can "fail fast".  This includes also covering the MEMWRITE ioctl which
>> previously missed checking for this.
> 
>> +	/* "safe" commands */
>> +	case MEMGETREGIONCOUNT:
> 
> I wonder if MEMSETBADBLOCK, MEMLOCK/MEMUNLOCK, BLKPG, OTPLOCK and
> MTDFILEMODE should be in the list of "safe" commands? Sounds like they
> can do at least as much damage as average MEMWRITE...

Most of the ioctls you listed are not write-exclusive because existing
user space applications (such as mtd-utils) issue them on a read-only fd.
So, we didn't want to break them.
Before we move such an ioctl to the "non-safe" list, common user space needs to
be inspected. This includes, android, openwrt, mtd-utils, etc...

On the other hand, this is a raw mtd, it is hard to draw the line.
For NAND even reading allows an attacker doing harm, she can trigger read-distrurb
super efficiently using the read ioctl...

So passing an mtdchar fd (no matter whether read or write mode) to untrusted
entities is a bad idea.

Thanks,
//richard