Can Sup Forums fix a security issue in TAILS?

Can Sup Forums fix a security issue in TAILS?
The TAILS team have not been able to fix the loophole where one can retrieve VRAM from a graphics card in a shutdown computer. hsmr.cc/palinopsia/

A ticket has been open for a couple years, and ideas have been given, yet there's been no conclusive answer.
labs.riseup.net/code/issues/5356

The best lead is "Basically, become root, find the PCI BAR where VRAM's mapped, and walk over it. There's a couple things called mmapw and mmapr that can help you; Google for them."

Other urls found in this thread:

hsmr.cc/palinopsia/
labs.riseup.net/code/issues/5356
twitter.com/SFWRedditGifs

well it's volatile, isn't it? sure they probably cover their tracks in normal ram but VRAM isn't something police would have tools for afaik. i can see how it wouldn't be high priority.

Can anyone provide a study where people successful retrieve valuable info from RAM, let alone VRAM?

True, yet the memory takes time to disappear

As long as a team isn't on standby to freeze the vram from power off you should be fine in regards to the RAMs

It's easy to retrieve info if the computer is still powered on

As I implied here it's possible to "freeze" volatile memory before it loses its memory

Results heavily depend on the graphics driver and the card used as seen in the Palinsopsia Bug hsmr.cc/palinopsia/

Fucking seriously?
Do you think cops will bring freezing gas to your house just to take data from your RAM?

They just need a bag, there's about a minute or so of leeway between power off and lost memory

And depending on your status with the government, they certainly might. Doesn't even need to be police, anyone can do it

This may sound stupid, but before shutdown, wouldn't it be possible to simply flood the VRAM with random/pseudo-random bits? Even just replacing it with a set pattern would simply overwrite what was last in VRAM, no?
It'd be kind of a hack, but it'd work until a real solution is found.

that's what he means by 'walk over it'.

Alright, I understand. Does TAILS automatically do this on shutdown or is it something the user has to do?
If no side effects occur from walking over the VRAM, should there be a reason to not include it?

>tails
>hosted by riseup

REEEEEEEEEEE
ANTIFAA
REEEEEEEEEEE

SNOWDEN MUST BE ANTIFA TOO
REEEEEEEE
(pol told me riseup is antifa)

>RiseUp

OP, are you some kind of Antifa shill? Do you use Firecuck as well?

I didn't read your link.

This guy is saying that if the computer is REBOOTED then RAM isn't completely erased and, interestingly, that a guest can read framebuffer a from the host system.

As far as security goes, just make sure you completely shutdown your device between changing OSes for security. You really should be using a distinct device though for TAILS.

The VM stuff is interesting though. I wonder if users on some large virtualised system like in a university could view framebuffer a of the host and capture anything interesting?

I agree it should be an option, yet it was ruled out since it would take too long and BIOS still writes to VRAM until the last second.

The only solution I see is to keep the allocated vram for TAILS at a minimal, like 32 to 128 MB then overwrite that available space, reboot, do so again, then maybe once more.

How does Sup Forums even know about riseup

It was linked from the TAILS website

ANTIFAAAAAAAAAAAAAAAAAAAAA

FUCK GNU/TAILS
LINUX IS FOR COMMIE SJW FAGGOTS

mozilla donated to tor and riseup and pol claimed it was antifa

I've always shut down and waited a while after using TAILS just in case, glad I've done so now. I don't use a separate system yet. I'm trying to tunnel TAILS through PIA though, which the only way I can do so is by IP forwarding from my laptop (that has PIA) on to the TAILS computer.

kek they're really stretching here

If I pay taxes that pay a government official who becomes ANTIFA, am I part of the Jewish problem too?

Mozilla may have gone SJW, yet they still seem to value privacy

What would the BIOS store into VRAM in the last second? I would understand concern if it were to compromise any files that were being viewed, but if all that was written to VRAM was more or less a shutdown screen, wouldn't that not be compromising to data was was being viewed on the machine?
Also, as for taking too long, perhaps it could have an option as to how it is shut down. Basically the fast way would not including walking over VRAM, the slow way would. Or, combine a low amount of VRAM accessible combined w/ that as an option.

I'm not entirely certain, but here's the conversation TAILS had with a professional video card driver writer from labs.riseup.net/code/issues/5356

MostAwesomeDude: is it possible to erase video ram for all types of video cards during shutdown?
You can't clear the VRAM until the computer's off, because the BIOS will keep writing to it up until the last second.
Is there a way to flush the vram then?
Basically, become root, find the PCI BAR where VRAM's mapped, and walk over it. There's a couple things called mmapw and mmapr that can help you; Google for them.

From context "clear" seems to mean empty the driver of electrons, and "flush" means to overwrite.

This makes more sense on why they don't overwrite
>As for using the OpenGPL API to write data to VRAM, I don't think that's reliable though, because you cannot write to arbitrary addresses. How do you know it would not just overwrite the same 32 MiB over and over? I guess you could try rendering something massive, but even then it would likely do some weird optimizations that leave some memory untouched.

After reading this through, I understand why it's been unsolved for four years.

You can't clear the electrons since the BIOS writes to it. And you can't overwrite the data because it's unreliable, and takes longer than it would take to dissipate upon power off.

It seems to be that physical access to a TAILS computer left powered on, or shut off for just a minute will remain a loophole in security, unless the graphic card hardware is changed.

Yet, it should still be possible to remove most of the risk by reducing the graphic memory allotted, and by sliding and over-writing the memory-mapped bar

they'll also bring a mouse wiggler and a hot swap ups