Hacker News Reader

Comment by jancsika | Hacker News Reader

FLAG_SECURE:

* overworked, out-of-coffee developer of "secure" messaging app forgets to set FLAG_SECURE. Oops.

vs.

FLAG_CACHE_ARBITRARY_IMAGE_OF_MY_INTERFACE_TO_HELP_ANDROID_APPEAR_MORE_RESPONSIVE:

* overworked developer of "secure" messaging app who is out of coffee forgets to set this flag. App doesn't appear more responsive but also doesn't cache an image of the interface. Yay security!

* But... app devs default to not caching images of interfaces, thus Android appears less responsive overall to the user.

FLAG_SECURE exists.

Therefore Android's appearance of responsiveness trumps secure defaults in this case.

Boo.

View on HN

But will anyone be harmed by these screenshots? They're encrypted.

How are they encrypted, if a disk scraper can find them and display the contents?

all user files are encrypted. no user password -> your disc scraper is useless.

They are encrypted on disk, but like an encrypted hard drive, decrypted when the user logs in. I'm unsure if they are accessible when the phone is locked, I don't think so. And apps can't access it. The drive scanner found them because they were in unallocated space.

They are definitely accessible by root even if the phone is locked. Unmounting & mounting the partition every time you lock/unlock is impossible as presumably some system services will still have open file handles there (for legitimate reasons), not to mention the performance impact.

The issue is that the OS now provides a convenient “backdoor” for root-privileged malware to capture sensitive data from any app effortlessly; it just needs to subscribe to file system events (using inotify) to grab the files as soon as they’re written. Without it, the malware developer would have to write hooks for each app they wanted to eavesdrop on individually, which raises the bar at least a little bit.

Linux fscrypt[1] [which Android uses for user data] doesn't work like that, you don't need to mount/unmount to decrypt: if the key is evicted from the linux keyring and the page cache is cleared, the user data will not be accessible on locked screen, even by root. It needs the a key in the kernel keyring to decrypt the pages associated with just the encrypted files. It's pretty neat!

[1] https://www.kernel.org/doc/html/v4.18/filesystems/fscrypt.ht...

This still means any open file handles would need to be closed and buffers flushed, right? That’s still a problem.

Correct, but I'm guessing the applications probably open files at a higher abstraction than a file handle [the curse/gift of Java], so it wouldn't be hard to decouple the file handle, and allow a trigger to close the file handle and sync on logout.

From a purely kernel perspective: it has been some time since I last looked at the kernel fs/dentry code, but from what I remember, the open file handle would hold refs for dentries that comprise the path [all the way up to mount root]. But even that wouldn't prevent other dentries from being cleared anyhow: only the open file would have unencrypted pages in the page cache. I would highly recommend reading the linux fscrypt code if you would like more details: it's very well structured and quite easy to get into!

Of course, the foolproof way would be to check lsof and nuke all processes that still have file handles open before logging out, but that's probably too much heresy :)

Correction: FLAG_SECURE doesn't make app "less responsive". It makes it appear as a header with a blank rectangle beneath in Recent apps, which lessens the UX but not responsiveness

Reply on news.ycombinator.com