linux-kernel - Re: [PATCH v2] module: Harden STRICT_MODULE

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: <20200810092523.GA8612@linux-8ccs>
Date:   Mon, 10 Aug 2020 11:25:23 +0200
From:   Jessica Yu <jeyu@...nel.org>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>, h@...ux-8ccs
Cc:     Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        keescook@...omium.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        Miroslav Benes <mbenes@...e.cz>
Subject: Re: [PATCH v2] module: Harden STRICT_MODULE_RWX

+++ Mauro Carvalho Chehab [08/08/20 10:12 +0200]:
[snip]
>Right now, what happens is:
>
>	# modprobe wlcore
>	modprobe: ERROR: could not insert 'wlcore': Exec format error
>
>This seems to be failing for all modules, as doesn't show anything
>probed.
>
>Btw, IMO, it would be useful to have some pr_debug() infra in order to
>explain why insmod is failing, or to have more error codes used there,
>as nothing was printed at dmesg. That makes harder to debug issues
>there. I ended losing a lot of time yesterday rebuilding the Kernel
>and checking the FS, before deciding to add some printks inside the
>Kernel ;-)
>
>In order for modprobe to start working again, I had to apply this
>dirty hack:
>
><hack>
>diff --git a/kernel/module.c b/kernel/module.c
>index 910a57640818..10d590dc48ad 100644
>--- a/kernel/module.c
>+++ b/kernel/module.c
>@@ -2051,11 +2051,12 @@ static int module_enforce_rwx_sections(Elf_Ehdr *hdr, Elf_Shdr *sechdrs,
> 	const unsigned long shf_wx = SHF_WRITE|SHF_EXECINSTR;
> 	int i;
>
>+#if 0
> 	for (i = 0; i < hdr->e_shnum; i++) {
> 		if ((sechdrs[i].sh_flags & shf_wx) == shf_wx)
> 			return -ENOEXEC;
> 	}
>-
>+#endif
> 	return 0;
> }
></hack>

All this hunk does it reject loading modules that have any sections
that have both the writable and executable flags. You're saying it's
happening for all modules on your setup - I am curious as to which
sections have both these flags - what does readelf -S tell you?

Thanks,

Jessica