linux-kernel - Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on coreboot console

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: <CAODwPW9d5ymdvAEfQZ0=A6cUv5zSVQLp6ML3korwjM0bhmGDNA@mail.gmail.com>
Date:   Mon, 22 May 2017 18:36:44 -0700
From:   Julius Werner <jwerner@...omium.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Julius Werner <jwerner@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Aaron Durbin <adurbin@...omium.org>
Subject: Re: [PATCH] firmware: google: memconsole: Prevent overrun attack on
 coreboot console

Fixes: a5061d028 ("firmware: google: memconsole: Adapt to new coreboot
ring buffer format")

On Sat, May 20, 2017 at 1:32 AM, Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Fri, May 19, 2017 at 02:44:38PM -0700, Julius Werner wrote:
>> The recent coreboot memory console update (firmware: google: memconsole:
>> Adapt to new coreboot ring buffer format) introduced a small security
>> issue in the driver: The new driver implementation parses the memory
>> console structure again on every access. This is intentional so that
>> additional lines added concurrently by runtime firmware can be read out.
>>
>> However, if an attacker can write to the structure, they could increase
>> the size value to a point where the driver would read potentially
>> sensitive memory areas from outside the original console buffer during
>> the next access. This can be done through /dev/mem, since the console
>> buffer usually resides in firmware-reserved memory that is not covered
>> by STRICT_DEVMEM.
>>
>> This patch resolves that problem by reading the buffer's size value only
>> once during boot (where we can still trust the structure). Other parts
>> of the structure can still be modified at runtime, but the driver's
>> bounds checks make sure that it will never read outside the buffer.
>>
>> Signed-off-by: Julius Werner <jwerner@...omium.org>
>
> Care to provide a "Fixes: SHA" type line here saying what commit this
> fixes the issue for, to allow people to know what is going on.
>
> thanks,
>
> greg k-h