full-disclosure - Xfree86 video buffering?

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: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Xfree86 video buffering? 

On Thu, 24 Feb 2005 14:35:27 PST, Eric Paynter said:

> All kidding aside, this seems to be a real security issue. Your system
> shouldn't be showing unauthorized users what you were doing. It should
> properly flush the memory.
> 
> Does a power off flush it?

I've seen this behavior on a Dell Latitude C840 laptop as well, and it has on
occasion even survived a power cycle of a few seconds.  This was with NVidia's
binary drivers on a GeForce 440Go card (so it isn't the VESA driver doing
this).  Basically, what's happening is that the on-card buffers for texture
memory and save-unders and pixmap storage aren't being cleared.

I don't think this is at all easily solvable - when the X server starts up, the
card is probably in console mode using the VGA emulation, which is pretty
brain-dead and doesn't touch much of the card memory (when you have 32M or 64M
on-card, that 640x480 gets lonely sitting in the corner).  The X server first
has to pop it into the native NVidia/ATI/whatever graphics mode (remember, it
has to do that *before* it can access the video memory - you can't get there
while still in VGA emulation).  Then it can proceed to clear out the on-card
memory.  Unfortunately, if the X server pauses in between setting the mode and
clearing  the memory, you get to see the uninitialized (and therefor left-over)
buffers.  About the best you can do here is fix the server to try to not do any
time-intensive operations between the mode set and the clear.

There's multiple reasons why it can even survive a power cycle.  In my case,
I've only been powering off for a few seconds (stupid laptop doesn't have a MNI
Reset button, which would be quite helpful when doing kernel-level hacking),
and the voltage levels in the RAM hadn't decayed all the way to bit lossage.
It's also quite possible that some video cards are made with static ram rather
than dynamic ram, which greatly increases the chances that the bits will
survive even an extended power-off, and/or the power "off" isn't really all the
way "off" - if the machine supports "suspend to RAM", it may be keeping a very
low trickle of power going to keep the memory from going poof....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050224/29eaec5c/attachment.bin