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]
From: stan.bubrouski at gmail.com (Stan Bubrouski)
Subject: Re: Xfree86 video buffering?

Riad S. Wahby wrote:

>Stan Bubrouski <stan.bubrouski@...il.com> wrote:
>  
>
>>With this solution someone could intentionally crash your machine to
>>avoid those routines from running.  I'm not trying to put you down or
>>anything, in fact I probably know less about video related stuff than
>>most on the list, this just doesn't seem like the best way to do it.
>>I have no better suggestions, I'll leave this one to the experts.
>>    
>>
>
>You've found a valid case where clear-on-shutdown breaks, but your
>solution doesn't solve the problem, it exacerbates it!
>
>  
>

Umm I didn't offer a solution at all?  I clearly said I wasn't wise 
enough to devise a
solution for this... which is why I said I'll leave a solution to the 
experts...

>Let's consider the threat here.
>
>- I'm looking at something sensitive on my screen.
>- I shut down my computer.
>...some time passes...
>- Mallory boots my computer and reads out the buffers from my video
>  card, thereby obtaining the sensitive information.
>
>By your proposal, we _intentionally_ leave the data on the video card
>until Mallory already has access to the machine, trusting that he'll
>be stupid enough to load our clear-on-startup video card drivers before
>dumping out the framebuffer.
>
>  
>

Can you read?  I didn't propose any solution I just poked holes in 
someone else's???

>The alternative, to clear-on-shutdown, is obviously better under
>normal circumstances, since sensitive data are never left in the
>framebuffer. In an exceptional case such as the computer crashing and
>failing to clear the framebuffer, it's true that the data remain on the
>card. Note, however, that we're in the same situation post-crash that
>we'd _always_ be in under your proposed system.
>
>  
>

WHAT PROPOSED SYSTEM?????

>It's obvious that clear-on-startup is strictly worse than clear-on-
>shutdown; implementing the latter will prevent a casual observer from
>seeing anything sensitive on the screen at startup, but it doesn't
>actually grant you any more security, since the data are still
>physically on the card.  Implementing both gives you a slight edge
>against a passive attacker in a small range of exceptional cases, so it
>might be the right way to do things.
>
>  
>

I don't think things are that clear at all.  In fact I don't know that 
ANYONE has actually
fully explained the problem and why it is occurring in the first place.

>Has anyone ever noticed this behavior with Windows, say, after a crash?
>I'm not saying I have (haven't actually run a Windows machine regularly
>in years, so I probably wouldn't remember anyway), I'm just curious.
>
>  
>
I've never observed this problem during the 5 years I've used windows 
2000.  However come to think of
it this problem isn't new.  I remember back in '99 my old p166 which 
indeed used the
vesa driver did this too.  So umm its probably been brought up many 
times before.

Please read things more carefully before responding.  All I did was 
offer a lame hypothetical situation in
which someone else's solution wouldn't work.

-sb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ