qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [BUG] user-to-root privesc inside VM via bad translatio


From: Peter Maydell
Subject: Re: [Qemu-devel] [BUG] user-to-root privesc inside VM via bad translation caching
Date: Wed, 22 Mar 2017 15:04:35 +0000

On 22 March 2017 at 14:55, Pranith Kumar <address@hidden> wrote:
> On Mon, Mar 20, 2017 at 10:46 AM, Peter Maydell wrote:
>> On 20 March 2017 at 14:36, Jann Horn <address@hidden> wrote:
>>> This is an issue in QEMU's system emulation for X86 in TCG mode.
>>> The issue permits an attacker who can execute code in guest ring 3
>>> with normal user privileges to inject code into other processes that
>>> are running in guest ring 3, in particular root-owned processes.
>>
>>> I am sending this to qemu-devel because a QEMU security contact
>>> told me that QEMU does not consider privilege escalation inside a
>>> TCG VM to be a security concern.
>>
>> Correct; it's just a bug. Don't trust TCG QEMU as a security boundary.
>>
>> We should really fix the crossing-a-page-boundary code for x86.
>> I believe we do get it correct for ARM Thumb instructions.
>
> How about doing the instruction size check as follows?
>
> diff --git a/target/i386/translate.c b/target/i386/translate.c
> index 72c1b03a2a..94cf3da719 100644
> --- a/target/i386/translate.c
> +++ b/target/i386/translate.c
> @@ -8235,6 +8235,10 @@ static target_ulong disas_insn(CPUX86State
> *env, DisasContext *s,
>      default:
>          goto unknown_op;
>      }
> +    if (s->pc - pc_start > 15) {
> +        s->pc = pc_start;
> +        goto illegal_op;
> +    }
>      return s->pc;
>   illegal_op:
>      gen_illegal_opcode(s);

This doesn't look right because it means we'll check
only after we've emitted all the code to do the
instruction operation, so the effect will be
"execute instruction, then take illegal-opcode
exception".

We should check what the x86 architecture spec actually
says and implement that.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]