From: Itay Iellin <ieitayie@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: torvalds@linuxfoundation.org, greg@kroah.com,
ebiederm@xmission.com, security@kernel.org,
viro@zeniv.linux.org.uk, jannh@google.com
Date: Mon, 16 Aug 2021 07:46:33 +0300 [thread overview]
Message-ID: <YRntqf83j2KzHoUm@itaypc> (raw)
Bcc:
Subject: fs/binfmt_elf: Integer Overflow vulnerability report
Reply-To:
I'm sharing a report of an integer overflow vulnerability I found (in
fs/binfmt_elf.c). I sent and discussed this vulnerability report with members
of security@kernel.org. I'm raising this for public discussion, with approval
from Greg (greg@kroah.com).
On Sun, Aug 01, 2021 at 04:30:30PM +0300, Itay Iellin wrote:
> In fs/binfmt_elf.c, line 1193, e_entry value can be overflowed. This
> potentially allows to create a fake entry point field for an ELF file.
>
> The local variable e_entry is set to elf_ex->e_entry + load_bias.
> Given an ET_DYN ELF file, without a PT_INTERP program header, with an
> elf_ex->e_entry field in the ELF header, which equals to
> 0xffffffffffffffff(in x86_64 for example), and a load_bias which is greater
> than 0, e_entry(the local variable) overflows. This bypasses the check of
> BAD_ADDR macro in line 1241.
>
> It is possible to set a large enough NO-OP(NOP) sled, before the
> actual code, modify the elf_ex->e_entry field so that elf_ex->e_entry+load_bias
> will be in the range where the NO-OP sled is mapped(because the offset
> of the PT_LOAD program header of the text segment can be controlled).
> This is practically a guess, because load_bias is randomized, the ELF file can
> be loaded a large amount of times until elf_ex->e_entry + load_bias
> is in the range of the NO-OP sled.
> To conclude, this bug potentially allows the creation of a "fake" entry point
> field in the ELF file header.
>
> Suggested git diff:
>
> Add a BAD_ADDR test to elf_ex->e_entry to prevent from using an
> overflowed elf_entry value.
>
> Signed-off-by: Itay Iellin <ieitayie@gmail.com>
> ---
> fs/binfmt_elf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 439ed81e755a..b59dcd5857db 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -1238,7 +1238,7 @@ static int load_elf_binary(struct linux_binprm *bprm)
> kfree(interp_elf_phdata);
> } else {
> elf_entry = e_entry;
> - if (BAD_ADDR(elf_entry)) {
> + if (BAD_ADDR(elf_entry) || BAD_ADDR(elf_ex->e_entry)) {
> retval = -EINVAL;
> goto out_free_dentry;
> }
> --
> 2.32.0
>
I am not attaching the replies to my initial report from the discussion with
members of security@kernel.org, only when or if I will be given permission
from the repliers to do so.
Itay Iellin
reply other threads:[~2021-08-16 5:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YRntqf83j2KzHoUm@itaypc \
--to=ieitayie@gmail.com \
--cc=ebiederm@xmission.com \
--cc=greg@kroah.com \
--cc=jannh@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=security@kernel.org \
--cc=torvalds@linuxfoundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).