On 09/09/2015 05:26 PM, Maarten Lankhorst wrote: > 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 at 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.
I am not even going that far, just talking about last frame stuck on screen. For me making that easier is a regression. Tvrtko
