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

Android Security Auditing: Investigating Unauthorized Screenshots

tech.michaelaltfield.net

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#21

Post by Rjevski »

epse wrote: post #20
clort wrote: post #17

Earlier quoted context omitted.

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

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.

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#22

Post by izacus »

RafiqM wrote: post #6
brodyprice wrote: post #3

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.

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.

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#23

Post by izacus »

ggm wrote: post #2

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.

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#24

Post by hefeweizen »

Rjevski wrote: post #21
epse wrote: post #20

Earlier quoted context omitted.

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 effort…

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

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#25

Post by Rjevski »

hefeweizen wrote: post #24
Rjevski wrote: post #21

Earlier quoted context omitted.

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 effort…

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/ht…

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

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#26

Post by saagarjha »

izacus wrote: post #22
RafiqM wrote: post #6

Earlier quoted context omitted.

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.

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.

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

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#27

Post by solarkraft »

RafiqM wrote: post #6
brodyprice wrote: post #3

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.

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

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#28

Post by solarkraft »

procinct wrote: post #12
jarfil wrote: post #10

Earlier quoted context omitted.

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

Why are you not a fan of 1Password?

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.

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#29

Post by hefeweizen »

Rjevski wrote: post #25
hefeweizen wrote: post #24

Earlier quoted context omitted.

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/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 :)

Re: Android Security Auditing: Investigating Unauthorized Screenshots

#30

Post by izacus »

saagarjha wrote: post #26
izacus wrote: post #22

Earlier quoted context omitted.

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.

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

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.

Post reply on HN