[qubes-users] Re: epoxy on ram to prevent cold boot attacks?
On Wednesday, August 31, 2016 at 8:25:33 PM UTC+4, pixel fairy wrote: > poured some epoxy over where the ram connects to the motherboard modern RAM keeps data after hours after disconnecting in from MB. (wont search that paper now, plz search on your own). there are also physical traces of RAM state on RAM device. thats why some folks are moving keys in RAM(xoring it actually) every 10 seconds or so, in their opensource encryption software. there is papper on in too, with photo of such physical micro traces. paper also explains why RAM manufacturers are trying to keep volts as low as possible. imo encrypted RAM is more safe. but where to store keys? CPU cache, VRAM? or separate PCI device? unsure about speed of PCI vs RAM though. but safe storing keys in HW of major, massive vendors is a wrong idea because of obligatory unofficial backdooring. maybe it is possible to only encrypt part of RAM with PCI located key(original PCI storage device). example: main system is in RAM, VM's RAM is encrypted (using driver) and the key is on PCI storage device. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/512950a4-6d96-4698-833d-ccf20ba33f9d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: epoxy on ram to prevent cold boot attacks?
Marek Marczykowski-Górecki: > If you (or someone else) plug a malicious USB device that will exploit > some bug in one of million USB device drivers, it can do whatever it > want with the other USB devices on the same bus. And if that USB > controller live in dom0, it's game over even without injecting malicious > keystrokes. > PS/2 is much better, because you can't connect anything else than input > devices there, and attack surface is much smaller. After having read the entirety of the PC security paper Joanna wrote a while back, I was shocked to see how poor PC security really is. I found it one of the most profound papers I've ever read. As far as I'm concerned, it should be required reading for anyone capable of understanding even the basics. What you wrote reminds me of that feeling and how wide open and vulnerable things really are for those that know what they're doing. It's amazing to me things have been "allowed" to get this bad. All genuine efforts into making things better are very much appreciated and needed by all of us. Thank you. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/nqcosk%24rm2%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz@gmail.com > wrote: > >> An actual protection would be some kind of a chemical that would destroy >> the ram chips if they ever reach certain (lower than room) temperature. > > the epoxy is likely to damage them in most means of removal. I guess most people have shinier (literally, on the contacts) new hardware than I do, but I know now and then I need to re-seat my RAM chips when the system gets cranky. Epoxy would a pretty costly measure (probably destroying the motherboard as well as the RAM). I guess I'd have to get a shinier new mobo in that case. :) I think case security and case (and room) intrusion detection is a bit more "civilized." > i know of things that can do their damage when they reach a certain > temperature or higher. never heard of one set off by going below a certain > temp. While interesting, that seems like a bad idea. Unless you're UPS'd up and never need to modify your hardware, insert/remove a card, whatever, you're gonna have a bad day eventually and lose your ram/mobo. > erasing on power loss would be good too, esp if the attacker doesnt know > about it. This, I do like, possibly hooked into case intrusion. I might just look into that myself, see if there's certain RAM pins that can be safely grounded to wipe the RAM in a case of power outage. I expect it's more difficult than that, and that the RAM would have to be actively wiped, since a power-off should basically be more or less equivalent to grounding all the RAM pins, no? Now, frying the memory with a high voltage zip from a charged up cap, say, on some chip-enable line or whatever, if there is a case intrusion without the proper trick done to disable it (such as a 16-dip-switch combination lock that has to be set properly) might be kind of cool. :) You'd want some gate to isolate that line (or thew whole chip) from the motherboard, to protect it. Maybe a capsule of acid on the ram chips (and contained to only affect them) that gets popped on command. It'd be fun to burn the sticky fingers of any intruder, too. :) Getting a bit fanciful here... On that same line of thought, sending 120V to the case if it's opened while the power is on (which is the mode of action for a cold boot attack, I assume?) might be fun. You might want to remove your Underwriter's Lab logo from the PC if you rig that up, lol. Getting into "Home Alone" territory. If you keep your PC on when you're away from it (which I think is safer, and I guess is the situation when you need protection from a cold boot attack), you could do something like immediately start wiping the RAM upon case intrusion. That'd be harmless in the case of legitimate maintenance, too. Seems much cleaner. I wonder what the most straight forward method of stopping all multi-tasking and starting to wipe the ram would be. Could a dom0 bash script, watching an intrusion detection device, simply do an "xl pause" or whatever on all VM's and start writing to some /proc memory device? (That's probably not going to work, you'd need something more ring-zero-ey...? Perhaps in a device driver. When I try to use my on-board NVidia, it does a good job of locking up the computer and wiping the RAM itself, after awhile, lol.) It'd have to be reasonably fast at starting its work. And writing to 4g/8g of memory is going to take some time, in the best case. Which adds points in the favour of the more destructive high-voltage zap method. (Maybe not a sequential write, but a bit more randomized one would thwart any attacker better?) There may be some existing work done on this for xen; I might do a bit of research and report back if I find anything useful. Interesting subjects to ponder. In my case (pun intended), there's not anything sensitive or incriminating on my drive or in memory; it's more a matter of protecting privacy and attempting to stop ongoing harassment and illegal surveillance. Stealing some work designs or code or personal information would be annoying, but it wouldn't jeopardize my life, land me in jail, or have me detained for waterboarded or anything. So knowing someone was tampering is good enough for me, and what I have personally focused upon. I'd be interested in others' thoughts on leaving the PC on versus leaving it off. Lately, I've been leaving it on, but with an alternative OS (another Linux) whose sole purpose is to know if somebody's been mucking around. My actual useful drive, data, passwords, go with me. It's only slightly inconvenient, but so far it has been the quickest route towards some peace of mind until I'm 100% confident in physical security and tamper detection. Sorry for any digression. JJ > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to qubes-users+unsubscr...@googlegroups.com. > To post to this group, send
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
>> https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3
>
> I've looked at it few years ago and it was outdated/unmaintained at that
> time already. I gave up on setting this on Win 7. I bet now it's even
> harder.
Yes, weird how neglected it is. Do people not write utility software for
Windows now? Is it too locked down by MS (expensive signing) or too
insecure for anyone to bother coding?
Remote sound seems like the type of thing a lot of power users would want,
even on Windows.
>> When I assign a single USB drive to a VM, is dom0 still really in charge
>> of the USB bus, and just shuffling stuff back and forth to the VM(s)?
>
> If you assign a single USB device to VM (using qvm-usb or qvm-block),
> then yes - all the nasty USB stuff is still handled in dom0/sys-usb.
> Only assigning the whole USB controller (PCI device) to a VM will move
> USB processing out of dom0.
So other than the potential of bugs in the stack, and faking a
keyboard/mouse, there's really nothing a USB device could do to provoke
any action (break-in attempts) in dom0?
Would a USB Wifi dongle auto-configure as a second adapter on Qubes? (I
might check that myself later.)
Mass storage devices will be noted by dom0, but nothing silly like autorun
could happen (unless you set it up manually). Device impersonation is a
threat, I suppose. Can one USB device effectively "bus master" to probe a
disk or something like that?
Any other device type that could be a threat via USB?
As long as you have a solid stack and reject HID/network, USB might not be
quite as scary as I thought.
Once you get your keyboard/mouse off of USB. That recipe for rejecting
HID in one of those links worked great,
/etc/udev/rules.d/99-disable-usb-input.rules:
ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="usb",
ATTRS{authorized}=="1", \
ENV{PARID}="$id", RUN+="/bin/sh -c 'echo 0
>/proc/bus/usb/devices/$env{PARID}/authorized'"
Any new attempts to insert HID devices are ignored.
I suppose there's a window at boot time before udev configures where a
rogue USB device could impersonate a HID device and try to hijack the
system (e.g. right at grub). But supervising any boots for any oddness is
trivial (and a good idea).
>> https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev
>
> Very interesting project indeed. And it is packaged in Fedora!
N!!! Lol, I spent hours trying to get that to build. I had
checked for packages under debian-8, found none, so figured Fedora was
even less likely to have it (being more conservative).
I was even building it under a bare-bones Fedora-23 VM. I could have just
dnf'd it.
That's a great thing, presumably having undergone review from the Fedora
folks to be in the main repositories. (If Qubes can't in turn trust
Fedora and its repo, it's toast from the start.) But I assume you still
don't increase the amount of running dom0 software lightly.
Installing it only brought in libqb (102k) and itself (206k), so it's
fairly lightweight. Might see how well it agrees with dom0. :P
> But as you've noted below, if all we need can be done using udev rules,
> it's better to not introduce another complexity.
With Fedora's review (and a fairly small package), I feel a lot more
comfortable with it, perhaps as an option. Making it easier for people to
track/configure USB devices is a pretty compelling selling point.
Possibly outweighs the risk of the minimal additional of dom0 software.
> The whole idea of having separate USB VM is to not care about USB
> related compromise. It isn't fully possible with all kind of devices (like
> USB camera - compromised USB VM will be able to sniff the traffic), but
> it is surely an improvement.
Leaving any camera or microphone connected at all isn't for the highly
security conscious. :)
> It would make sense to have Disposable USB VM - I hope we'll manage to
> have it in Qubes 4.0.
That's interesting. So, for example, you could possibly configure it such
that if a certain device is inserted, a disposable VM could pop up,
attached to that USB device, that could then run an app (such as keepass).
When you're done, the DVM goes away. That's rather tidy. And safer.
I assume memory freed from a dead VM is wiped upon freeing by Xen? Or at
least wiped before allocating it elsewhere?
>> Some discussions online argue that USB white-listing isn't helpful,
>> since
>> a BADUSB could just emulate your actual keyboard. Well, it would have
>> to
>> know the device ID's first.
>
> Yes. But then, such device would be able to communicate with
> only one driver - of that keyboard. Not arbitrary chosen one of hundreds
> of them -> large reduction of attack surface.
I suppose even a brute-force search of device ID's through the relatively
few vendors is feasible (without some protection).
> Of course, if it hit unlocked system (or locked, but know the password),
> controlling keyboard means controlling the whole system. But you can
> guard against such attacks
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Sep 01, 2016 at 06:55:05AM -, johnyju...@sigaint.org wrote: > > On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote: > >> I'm curious to some mentions-in-passing about Andrew's hate for USB > >> keyboards. USB-anything isn't good for security, but what in particular > >> so much worse about USB? Both USB and PS/2 can keylog, or play > >> predefined > >> scripts to try and exploit the system. One of the dangers of rogue USB > >> devices is that they can suddenly pretend to be a keyboard (which Linux > >> will accept without confirmation, something I'm not thrilled about). > > > > It is mostly not about the keyboard itself, but other devices on the > > same bus. Anything that can control the bus to which keyboard is > > connected, can control the keyboard / pretend to be a keyboard. > > I can understand pretending to be the keyboard, but seeing the keyboard's > traffic, controlling the keyboard is really possible from another device > on the bus? If so, what a fatal flaw in the design of USB. On, it's about compromising system to which such USB device is connected. > > In addition, USB is quite complex and as with all complex code there are > > bugs. > > I hear you. I've bit-banged PS/2 protocols myself, and it's not that > hard. VUSB has achieved the same with USB, but its a *huge* project (and > can barely achieve HID use). > > > If you (or someone else) plug a malicious USB device that will exploit > > some bug in one of million USB device drivers, it can do whatever it > > want with the other USB devices on the same bus. And if that USB > > controller live in dom0, it's game over even without injecting malicious > > keystrokes. > > Yikes. USB really needs to get out of dom0 all together, just as > networking has. I'd also like to see the sound card in its own VM. With > Pulse's networkability, it shouldn't be that hard. One could use the > Pulse network ability instead of virtualization of the sound card. Actually our VM audio solution is based on something like this: passing raw samples (similar to pacat + module-simple-protocol-unix) over vchan link - socket-like inter-VM connection. See here: https://github.com/QubesOS/qubes-issues/issues/1590 > That might also be the best route to getting sound working in Windows > HVM's, although some work is needed on Windows Pulse clients: > > https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3 I've looked at it few years ago and it was outdated/unmaintained at that time already. I gave up on setting this on Win 7. I bet now it's even harder. > When I assign a single USB drive to a VM, is dom0 still really in charge > of the USB bus, and just shuffling stuff back and forth to the VM(s)? If you assign a single USB device to VM (using qvm-usb or qvm-block), then yes - all the nasty USB stuff is still handled in dom0/sys-usb. Only assigning the whole USB controller (PCI device) to a VM will move USB processing out of dom0. > > PS/2 is much better, because you can't connect anything else than input > > devices there, and attack surface is much smaller. > > Agreed. It's all I use for mouse/keyboard. > > > Some mitigation would be to use separate USB controller for USB > > keyboard/mouse and have it in dedicated VM (separate form all-purposes > > sys-usb). > > Another possibility is some built-in Qubes support for building udev rules > (similar to how the firewall makes iptables rules), or perhaps adding > USBGuard to dom0 (or any USB Qube). A good comparison of the two options > is here: > > https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev Very interesting project indeed. And it is packaged in Fedora! But as you've noted below, if all we need can be done using udev rules, it's better to not introduce another complexity. > Seems like a great idea for Qubes in mitigating USB dangers, since in > practice it is so hard to avoid USB all together. And that problem is > only getting worse. > > One dodgy USB device from the dollar store, and your pwned. Or an > NSA/syndicate-implanted commercial hard drive with alternate identities > lurking. The whole idea of having separate USB VM is to not care about USB related compromise. It isn't fully possible with all kind of devices (like USB camera - compromised USB VM will be able to sniff the traffic), but it is surely an improvement. It would make sense to have Disposable USB VM - I hope we'll manage to have it in Qubes 4.0. > Some discussions online argue that USB white-listing isn't helpful, since > a BADUSB could just emulate your actual keyboard. Well, it would have to > know the device ID's first. Yes. But then, such device would be able to communicate with only one driver - of that keyboard. Not arbitrary chosen one of hundreds of them -> large reduction of attack surface. Of course, if it hit unlocked system (or locked, but know the password), controlling keyboard means controlling
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> This is scary: > > https://hakshop.myshopify.com/collections/usb-rubber-ducky/products/usb-rubber-ducky-deluxe?variant=353378649 Related, and (disturbingly) informative: https://github.com/brandonlw/Psychson JJ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c2872d8b7c663d10b867f7b43b735ad3.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
> On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote: >> I'm curious to some mentions-in-passing about Andrew's hate for USB >> keyboards. USB-anything isn't good for security, but what in particular >> so much worse about USB? Both USB and PS/2 can keylog, or play >> predefined >> scripts to try and exploit the system. One of the dangers of rogue USB >> devices is that they can suddenly pretend to be a keyboard (which Linux >> will accept without confirmation, something I'm not thrilled about). > > It is mostly not about the keyboard itself, but other devices on the > same bus. Anything that can control the bus to which keyboard is > connected, can control the keyboard / pretend to be a keyboard. I can understand pretending to be the keyboard, but seeing the keyboard's traffic, controlling the keyboard is really possible from another device on the bus? If so, what a fatal flaw in the design of USB. > In addition, USB is quite complex and as with all complex code there are > bugs. I hear you. I've bit-banged PS/2 protocols myself, and it's not that hard. VUSB has achieved the same with USB, but its a *huge* project (and can barely achieve HID use). > If you (or someone else) plug a malicious USB device that will exploit > some bug in one of million USB device drivers, it can do whatever it > want with the other USB devices on the same bus. And if that USB > controller live in dom0, it's game over even without injecting malicious > keystrokes. Yikes. USB really needs to get out of dom0 all together, just as networking has. I'd also like to see the sound card in its own VM. With Pulse's networkability, it shouldn't be that hard. One could use the Pulse network ability instead of virtualization of the sound card. That might also be the best route to getting sound working in Windows HVM's, although some work is needed on Windows Pulse clients: https://freedesktop.org/wiki/Software/PulseAudio/FAQ/#index15h3 When I assign a single USB drive to a VM, is dom0 still really in charge of the USB bus, and just shuffling stuff back and forth to the VM(s)? > PS/2 is much better, because you can't connect anything else than input > devices there, and attack surface is much smaller. Agreed. It's all I use for mouse/keyboard. > Some mitigation would be to use separate USB controller for USB > keyboard/mouse and have it in dedicated VM (separate form all-purposes > sys-usb). Another possibility is some built-in Qubes support for building udev rules (similar to how the firewall makes iptables rules), or perhaps adding USBGuard to dom0 (or any USB Qube). A good comparison of the two options is here: https://dkopecek.github.io/usbguard/blog/2015/USBGuard-vs-UDev Seems like a great idea for Qubes in mitigating USB dangers, since in practice it is so hard to avoid USB all together. And that problem is only getting worse. One dodgy USB device from the dollar store, and your pwned. Or an NSA/syndicate-implanted commercial hard drive with alternate identities lurking. I'm always tempted, but ultimately avoid, unusually low-priced USB devices, lol. I've been passed USB keys from some rather suspect individuals in the past; I've quarantined them, and should (carefully, on a non-critical system) take a more detailed peek someday, lol. Some discussions online argue that USB white-listing isn't helpful, since a BADUSB could just emulate your actual keyboard. Well, it would have to know the device ID's first. Even if it gloms my keyboard's USB vendor/device ID's and tires to imitate it, the system could spot the fact that there's a second similar device but on another USB port, no? Or is USB so stupid that the system couldn't differentiate the two (or the fact that there is two)? While the USBGuard project looks admirable, I'm guessing the more attractive option would be for Qubes to add support for creating custom udev whitelists, as the less software in dom0, the better. Although USBGuard isn't a huge project (the tarball is <1M) and if you're going to otherwise have to write the code yourself, it might be better to just audit USBGuard and include it in some form. If someone else has already put in much of the required thought and effort . . . Even a pop-up notification when a new HID device is added could be useful. The fact that keyboard/mice are silently accepted is a bit scary. I might add some scripts to watch dmesg for such events, and more actively warn me. All just food for thought. I'll be adding udev whitelist rules to dom0 very shortly. Another idea I saw was restricting HID devices to *one* keyboard and *one* mouse, so if a BADUSB comes along trying to be another keyboard, it doesn't work. Or even better, alarm bells go off. I was thinking earlier that some form of a "USB Firewall" hardware device might be cool to create; one that goes into each USB port in between each device and the PC, and only passes a specific device, or only a HID device (and doesn't
Re: [qubes-users] Re: epoxy on ram to prevent cold boot attacks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Aug 31, 2016 at 10:05:59PM -, johnyju...@sigaint.org wrote: > I'm curious to some mentions-in-passing about Andrew's hate for USB > keyboards. USB-anything isn't good for security, but what in particular > so much worse about USB? Both USB and PS/2 can keylog, or play predefined > scripts to try and exploit the system. One of the dangers of rogue USB > devices is that they can suddenly pretend to be a keyboard (which Linux > will accept without confirmation, something I'm not thrilled about). It is mostly not about the keyboard itself, but other devices on the same bus. Anything that can control the bus to which keyboard is connected, can control the keyboard / pretend to be a keyboard. In addition, USB is quite complex and as with all complex code there are bugs. If you (or someone else) plug a malicious USB device that will exploit some bug in one of million USB device drivers, it can do whatever it want with the other USB devices on the same bus. And if that USB controller live in dom0, it's game over even without injecting malicious keystrokes. PS/2 is much better, because you can't connect anything else than input devices there, and attack surface is much smaller. Some mitigation would be to use separate USB controller for USB keyboard/mouse and have it in dedicated VM (separate form all-purposes sys-usb). This will guard you from potentially malicious devices *you* plug into the system, but not from someone else plugging it instead of keyboard (so into that keyboard-only USB controller). To plug that hole, that USB-keyboard VM should be configured to reject any non-keyboard device before allowing any driver to talk to it. This will still left you vulnerable for bug in USB stack itself, but the attack surface is much, much smaller than all the USB devices drivers (some unmanaged for years). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJXx5GcAAoJENuP0xzK19cstXgH/2+qnvTd7y00TSaUuAqjgUUI waSjgeZnXfuGn8WMIRaGn4sIAqG4VgL1JP8sStWGHzAktOnqU/BHmaMAgipVvDpy 60a0SumEE1kZ8RUbIzINuTlZVmXw/7Dt1NCA0FOJbkjn4UeiuRvCkKceedJXrV9a m3HoCGTu1qgZB9B4m+TvPtgeqUrUj/bvsLkgPJbVKiOWevIJ7M57cabDk/6P3p0q QMHT6yPqcEXrA3SKAay/LDTvwP6C67jXjkCsvQYPX1TNrCZzEkvYyA3P4ycblBlM Pq3MmSlPTLkiHorupOERDZi7mON2lss23aaj0AXvClgO03V8ArPjDnnmxHEWW9A= =za1M -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20160901022532.GE24732%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: epoxy on ram to prevent cold boot attacks?
On Wednesday, August 31, 2016 at 10:40:23 AM UTC-7, grzegorz@gmail.com wrote: > An actual protection would be some kind of a chemical that would destroy the > ram chips if they ever reach certain (lower than room) temperature. the epoxy is likely to damage them in most means of removal. i know of things that can do their damage when they reach a certain temperature or higher. never heard of one set off by going below a certain temp. erasing on power loss would be good too, esp if the attacker doesnt know about it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11f811f4-eaaf-41dc-824e-7f39b374bbdd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: epoxy on ram to prevent cold boot attacks?
W dniu środa, 31 sierpnia 2016 18:25:33 UTC+2 użytkownik pixel fairy napisał: > poured some epoxy over where the ram connects to the motherboard, and where > the clips are that you would use to take it out. the chips themselves dont > have any, just the surrounding pcb. > > this was couple days ago. so far its survived 2 reinstalls of test qubes > releases, and is doing one of rc3. > > i have this feeling im about to find out theres some simple way around this > and its not really a protection against cold boot attacks. i know some > laptops have easy bios resets, so thats one way. An actual protection would be some kind of a chemical that would destroy the ram chips if they ever reach certain (lower than room) temperature. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/37b7279f-2f8b-4f74-97d7-46171c02a7b5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
