
Android Security Auditing: Investigating Unauthorized Screenshots - mr-ron
https://tech.michaelaltfield.net/2018/11/09/android-security-auditing-investigating-unauthorized-screenshots/
======
brodyprice
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?

~~~
RafiqM
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.

~~~
solarkraft
I hate apps using FLAG_SECURE with full passion. I want to take a fucking
screenshot and you don't allow me to.

~~~
tjoff
Yeah, for some reason web browsers feel the need to do that when browsing in
private mode.

It is one thing to block automatic screenshots or screen recordings. Another
when the user explicitly tries to take a screenshot.

~~~
kbenson
I imagine the reasoning is that if you can do it, some other app might be able
to trigger it, and at that point, it's all downhill.

~~~
tjoff
It's an OS function triggered by a physical button. If some other app can
imitate that then surely it is already game over?

------
jancsika
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.

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

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

~~~
epse
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.

~~~
Rjevski
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.

~~~
hefeweizen
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...](https://www.kernel.org/doc/html/v4.18/filesystems/fscrypt.html)

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

~~~
hefeweizen
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 :)

------
ggm
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.

~~~
jarfil
I'm not a fan of 1password, but their Android app does block screenshots.

~~~
procinct
Why are you not a fan of 1Password?

~~~
solarkraft
I can tell you why I'm not. Their software is not open source. Plus an open
source competitor with good UX (and sync), Bitwarden, exists.

------
mr-ron
Disclaimer: This is not me, but someone I met through The Recurse Center (
[https://www.recurse.com/](https://www.recurse.com/) ), and was enthralled by
this story.

------
esotericn
Why can manual screenshots be prevented by applications?

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.

~~~
FactolSarin
How can the API ever be 100% sure it's a user-initiated screenshot?

~~~
esotericn
It's a physical button press.

------
burner222
can someone tell me why these cached interfaces are even leaving memory/RAM

