Re: [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

[Maarten Lankhorst <maarten.lankhorst@linux.intel.com>]

Op 09-09-15 om 18:15 schreef Tvrtko Ursulin:
>
> On 09/09/2015 05:07 PM, Daniel Vetter wrote:
>> On Wed, Sep 9, 2015 at 6:03 PM, Tvrtko Ursulin
>> <tvrtko.ursulin@linux.intel.com> wrote:
>>> It was just an example of a class of vulnerabilities which would be possible
>>> with these changes. If they, as you said, will preserve the last frame on
>>> screen when the compositor crashes.
>>
>> If your compositor crashes something should take over, either fbdev
>> (which force-restores) or a new compositor (system one or just the one
>> that crashed, restarted). And on modern userspace logind has copies of
>> the fds which it uses to make sure priviledges (i.e. master rights)
>> don't escape to the wrong person.
>
> The famous "should". fbdev is going out no? And attack just needs to prevent compositor from starting again. Or a bug somewhere needs to do that. Fact remains, before this = black screen, after this = last frame with bank details or similar.
>
> Change makes the scenario more likely, so what is the justification? Only that modeset is hard on framebuffer owner exiting?
>>> For me this is serious enough not to go this route.
>>
>> If that doesn't happen you have yet another bug in userspace. I don't
>> think there's a real problem really.
>
> If white hats had the imagination of black hats there would be no problems whatsoever. :)
>
> Tvrtko

I have enough imagination, but the fact is the code to copy the fb contents requires the following:

file_priv->is_master || capable(CAP_SYS_ADMIN) || drm_is_control_client(file_priv)

If you already have any of those privileges you can draw your own fake TTY login screen
and grab the password that way, so I don't see an additional attack vector exposed here.

~Maarten

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx