linux-kernel - Re: [PATCH] fs/open: Fix most outstanding security bugs

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: <20190401203514.GC1177@magnolia>
Date:   Mon, 1 Apr 2019 13:35:14 -0700
From:   "Darrick J. Wong" <darrick.wong@...cle.com>
To:     Johannes Thumshirn <jthumshirn@...e.de>
Cc:     Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>,
        Linux FSDEVEL Mailinglist <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] fs/open: Fix most outstanding security bugs

On Mon, Apr 01, 2019 at 11:01:13AM +0200, Johannes Thumshirn wrote:
> Over the last 20 years, the Linux kernel has accumulated hundreds if not
> thousands of security vulnerabilities.
> 
> One common pattern in most of these security related reports is processes
> called "syzkaller", "trinity" or "syz-executor" opening files and then
> abuse kernel interfaces causing kernel crashes or even worse threats using
> memory overwrites or by exploiting race conditions.
> 
> Hunting down these bugs has become time consuming and very expensive, so
> I've decided to put an end to it.
> 
> If one of the above mentioned processes tries opening a file, return -EPERM
> indicating this process does not have the permission to open files on Linux
> anymore.
> 
> Signed-off-by: Johannes Thumshirn <jthumshirn@...e.de>
> ---
>  fs/open.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/fs/open.c b/fs/open.c
> index f1c2f855fd43..3a3b460beccd 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -1056,6 +1056,20 @@ long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
>  	struct open_flags op;
>  	int fd = build_open_flags(flags, mode, &op);
>  	struct filename *tmp;
> +	char comm[TASK_COMM_LEN];
> +	int i;
> +	static const char * const list[] = {
> +		"syzkaller",
> +		"syz-executor,"
> +		"trinity",
> +		NULL
> +	};

This makes no sense, why would you gate on "syz-executor,trinity"?

> +
> +	get_task_comm(comm, current);
> +
> +	for (i = 0; i < ARRAY_SIZE(list); i++)
> +		if (!strncmp(comm, list[i], strlen(list[i])))
> +			return -EPERM;

This is insufficient, because this isn't the only way to open a file.

Wouldn't it be far more effective to use copy_to_user to inject
shellcode into the syzkaller image and change the return address, to
find all the places where syzbot doesn't validate itself sufficiently?
In Soviet Russia, the kernel syzkallz you.

NAK.

--D

>  
>  	if (fd)
>  		return fd;
> -- 
> 2.16.4
>