Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I recovered a lost email from my email client’s memory

ctrl.blog

Post reply on HN
Print view View original

81–85 of 85 posts

Re: How I recovered a lost email from my email client’s memory

#81

Post by saagarjha »

d2wa wrote: post #76
saagarjha wrote: post #73

Earlier quoted context omitted.

I use nano, but I have to say I am very surprised that they mentioned it as a viewer for large binary files. It reads the entire file off of disk into memory and then tries to split it into lines! It can't even do well on files with large enough lines :(

Nano reads large files in chunks. Other text editors do indeed pull in the entire file before doing anything useful.

No, it reads the whole file at once: https://git.savannah.gnu.org/cgit/nano.git/tree/src/files.c#....

Re: How I recovered a lost email from my email client’s memory

#82

Post by xfitm3 »

segfaultbuserr wrote: post #44
WrtCdEvrydy wrote: post #18

Earlier quoted context omitted.

If you don't want to pay for HotPlug, you can also grab a full memory dump using FTK Imager or Belkasoft...

It's why operating systems should implement a lockdown option to restrict users from performing arbitrary access to memory or kernel, even if the user is root. I mentioned before that, on one of my computer, I completely disabled dynamic kernel modules, hotpatching, /dev/mem, no ptrace() to arbitrary process, etc., making it difficult for root to do any low-level access to memory or kernel. I also enabled IOMMU, it i…

I forgot all about grsec - sad to see its no longer publicly available. Thanks for the tip on IOMMU and your other measures.

Re: How I recovered a lost email from my email client’s memory

#83

Post by dredmorbius »

mellow2020 wrote: post #49
dredmorbius wrote: post #34

I used to (when this was still possible) dump /proc/memory (or kmem?) to file and rummage through it looking for partially composed website submissions when Netscape decided to eat itself, back in the 1990s. Remarkably successsful.

Using Process Explorer at least, it's still just a right click on any process away.

There used to be a global system memory file in /proc, 2.0 / 2.2 kernel series, unless my memory's playing tricks on me. Even content from dead processes was still (briefly) available.

Re: How I recovered a lost email from my email client’s memory

#84

Post by pabs3 »

Wowfunhappy wrote: post #80
pabs3 wrote: post #77

Earlier quoted context omitted.

elementaryOS' mail client is now a separate implementation to Geary and is based on libraries that underly the Evolution mail client. https://github.com/elementary/mail

Yep, but my understanding was the Geary's lineage was the same in that both projects originally grew up together before elementary decided to change direction. Not true?

Right, they used to share lineage but don't any more.

Re: How I recovered a lost email from my email client’s memory

#85

Post by segfaultbuserr »

xfitm3 wrote: post #82
segfaultbuserr wrote: post #44

Earlier quoted context omitted.

It's why operating systems should implement a lockdown option to restrict users from performing arbitrary access to memory or kernel, even if the user is root. I mentioned before that, on one of my computer, I completely disabled dynamic kernel modules, hotpatching, /dev/mem, no ptrace() to arbitrary process, etc., making it difficult for root to do any low-level access to memory or kernel. I also enabled IOMMU, it i…

I forgot all about grsec - sad to see its no longer publicly available. Thanks for the tip on IOMMU and your other measures.

Just a note for you (and other readers), as I think it needs some elaboration.

> no ptrace() to arbitrary process

Traditionally, ptrace() restriction is a grsec feature. But in mainline kernels, the same feature is available in the Yama module, see [0]. Use Yama with "kernel.yama.ptrace_scope = 3" will permanently disable ptrace() for all users, including root, and it cannot be enabled again. Then, you should also compile your own kernel, so you can disable /dev/kmem (CONFIG_DEVKMEM), /dev/mem (CONFIG_DEVMEM) and /proc/kcore (CONFIG_PROC_KCORE) in the Linux kernel. Also, I forgot to mention kexec(), which allows the attacker to execute another kernel without rebooting, so CONFIG_KEXEC should be disabled as well. And the list goes on and on, I think it's necessary to download an old grsec kernel, and using the configuration section of grsec as a checklist (and try disabling them using mainline technique if possible) if your security is serious business.

If you do these things, it will block the technique described in the original article.

[0] https://www.kernel.org/doc/Documentation/security/Yama.txt

Post reply on HN