Android Security Auditing: Investigating Unauthorized Screenshots
tech.michaelaltfield.net
tech.michaelaltfield.net
Can someone explain to me what the problem is? Why are the screenshots considered unauthorized?
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.
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)
It is one thing to block automatic screenshots or screen recordings. Another when the user explicitly tries to take a screenshot.
Your conversations aren't nearly as sensitive to require such a large breach of usability.
Yours might not be, but this isn’t true for everyone.
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.
Because your sentence just sounds like platitude without any thought behind it.
* 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.
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.
[1] https://www.kernel.org/doc/html/v4.18/filesystems/fscrypt.ht...
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 :)
Automated screenshots - makes sense.
But manual? I've lost count of the number of times I've had to resort to stupid nonsense like taking a photo of my phone with another phone.
It provides zero security benefit whilst making the end user's life harder.