The screenshots were for "recent apps" navigation, they weren't being uploaded anywhere, apps can set "FLAG_SECURE" to prevent it, the device was rooted, and the files were "...inaccessible to most apps, except those to which I grant root access." ?
Can someone explain to me what the problem is? Why are the screenshots considered unauthorized?
The conclusion is there's no problem, that it wasn't the nefarious activity that he originally thought it was.
The additional point he's trying to make is that app developers should use FLAG_SECURE if its confidential data - messaging probably should be, and his bitcoin app should almost certainly be.
Keepass2Android and Signal have it as an option, Orfox just enables it on webpages but disables it on the settings screen, Netflix enables it on video playback. My banking app doesn't have the option at all, yay banking!
I know some password managers (myki, lastpass and I think 1Password have an option to toggle it off).
It's on by default, which should be true for most apps with confidential data. But other apps (like photos and messaging apps, can at least have that as an option defaulted to false, for users who would like the extra privacy)
How is messaging confidental data? Remember, FLAG_SECURE prevents users from taking screenshots themselves as well and prevents display of content in several other cases (e.g. screen mirroring).
Your conversations aren't nearly as sensitive to require such a large breach of usability.
I think the broader point is that it stops the user doing something they want to. Something they could still do with a camera.
The flag should secure it from other apps but the user screenshot tool should be able to override it. The cap framework should be able to do this, you just need to insulate the app itself to ensure only real people can use it.
I'd be happy to hear about an attack vector that compromises encrypted private OS storage on Android, but does not compromise the apps view hierarchy rendered by the same OS. FLAG_SECURE is just an OS flag though.
Because your sentence just sounds like platitude without any thought behind it.
Preventing screenshots and showing up in the active apps list is an option within the Signal preferences. So Signal provides a precautious default, but allows you to turn it off.
Ah, that makes sense, thank you. I think I was thrown off by the link's title, "Unauthorized Screenshots in Android Phones" - I read it as a security issue
That makes sense, thanks! I guess the title just sounded like they were highlighting it as a problem, "Unauthorized Screenshots in Android Phones" sounds concerning
* 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.
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!
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
I did tell 1password I could see 'en clair' state in the recent apps view some number of versions ago. They said there wasn't much they could do about it.
1Passwords Android app quality is pretty lacking in comparison to any other competitor, so it's not wierd that they didn't even enable the secure flag.
Can someone explain to me what the problem is? Why are the screenshots considered unauthorized?