K-9 Mail will no longer load emails after update: N2G48B.2017.07.06.00.04.39 release

[theGrower]

emails will be fetched into the app from server; however, upon attempting to open the email no content will be loaded. The "Show pictures" button does not work either.

This is true for gmail, live.com, and various other email server using IMAP and POP that were all previous working.

[thestinger]

Does anything similar happen with any non-Email related apps?

It would be useful to obtain the relevant log output from when this happens via adb logcat -d > log.txt. You could run adb logcat -c, then launch relevant app, and make it break, to obtain the minimal required output. Can email that to daniel.micay@copperhead.co in case it ends up with sensitive information (like a logged email address by an app), or post it here if it clearly doesn't have any (could also edit it out if necessary).

[thestinger]

Does anything similar happen with any non-Email related apps?

It would be useful to obtain the relevant log output from when this happens via adb logcat -d > log.txt. You could run adb logcat -c, then launch relevant app, and make it break, to obtain the minimal required output. Can email that to daniel.micay@copperhead.co in case it ends up with sensitive information (like a logged email address by an app), or post it here if it clearly doesn't have any (could also edit it out if necessary).

[theGrower]

I'll have to try this later at home. The content of the emails does show in brief form (as expected) in the quick pulldown notification.

I'm not noticing anything else in other apps at the moment.

[theGrower]

I'll have to try this later at home. The content of the emails does show in brief form (as expected) in the quick pulldown notification.

I'm not noticing anything else in other apps at the moment.

[thestinger]

Can you make sure Chromium works for you and that the PDF Viewer app works?

[thestinger]

Can you make sure Chromium works for you and that the PDF Viewer app works?

[theGrower]

I take that back, the CaptivePortalLogin isn't loading either. I have to bypass that to a browser.

[theGrower]

I take that back, the CaptivePortalLogin isn't loading either. I have to bypass that to a browser.

[mke208]

Just compiled from source, and k9 is loading content correctly. I do not have a way to test CaptivePortalLogin now, but if the bug is related, it might have been fixed too.
N2G48B.2017.07.06.18.40.09 (UTC)

[mke208]

Just compiled from source, and k9 is loading content correctly. I do not have a way to test CaptivePortalLogin now, but if the bug is related, it might have been fixed too.
N2G48B.2017.07.06.18.40.09 (UTC)

[thestinger]

Which version of the sources did you compile? The N2G48B.2017.07.06.18.40.09 version if your own version based on when you built it.

[thestinger]

Which version of the sources did you compile? The N2G48B.2017.07.06.18.40.09 version if your own version based on when you built it.

[mke208]

copperheados-nougat-mr2-release - devel branch

[mke208]

copperheados-nougat-mr2-release - devel branch

[mke208]

synced & built about 2 hours ago

[mke208]

synced & built about 2 hours ago

[thestinger]

Ah, so then this is probably fixed by the same two workarounds.

• CopperheadOS/platform_frameworks_base@310564c
• CopperheadOS/platform_frameworks_opt_net_wifi@b114c9d

[thestinger]

Ah, so then this is probably fixed by the same two workarounds.

• CopperheadOS/platform_frameworks_base@310564c
• CopperheadOS/platform_frameworks_opt_net_wifi@b114c9d

[thestinger]

PERMISSIONS_REVIEW_REQUIRED is an upstream feature I enabled for the latest release and it turns out there were some low important broken bits that they added much more recently than the main feature which is robust, so those half baked bits are temporarily disabled.

[thestinger]

PERMISSIONS_REVIEW_REQUIRED is an upstream feature I enabled for the latest release and it turns out there were some low important broken bits that they added much more recently than the main feature which is robust, so those half baked bits are temporarily disabled.

[mke208]

I guess for now it is fixed, as everything seems to be working fine.
off-topic: where can i find the key id, the one that nexus devices display on the yellow boot screen ?

[mke208]

I guess for now it is fixed, as everything seems to be working fine.
off-topic: where can i find the key id, the one that nexus devices display on the yellow boot screen ?

[thestinger]

It's not supported by the Pixel bootloader yet. I reported the spec violation to Google and they acknowledged it as a bug. I think it was either forgotten or someone cut a corner to meet deadlines and it wasn't noticed by Google.

[thestinger]

It's not supported by the Pixel bootloader yet. I reported the spec violation to Google and they acknowledged it as a bug. I think it was either forgotten or someone cut a corner to meet deadlines and it wasn't noticed by Google.

[mke208]

Yes, but is there any way to "see" it after boot ? Maybe as root ?

[mke208]

Yes, but is there any way to "see" it after boot ? Maybe as root ?

[thestinger]

It's in the kernel command-line, but that isn't visible without root and there's no value in verifying it that way. Note that just because it's not visible doesn't mean that an attacker with root can write out partitions signed with another key. Your encryption key couldn't be derived anymore by the TEE since the bootloader would pass a different verified boot key.

It can be obtained from the https://developer.android.com/training/articles/security-key-attestation.html API. The bootloader passes it to the TEE and then the TEE can provide the current key in a way that provides proof it's the current one. The proof is stronger when there's already pairing vs. using Google's included key attestation root. Someone would need to implement an app to do this.

[thestinger]

It's in the kernel command-line, but that isn't visible without root and there's no value in verifying it that way. Note that just because it's not visible doesn't mean that an attacker with root can write out partitions signed with another key. Your encryption key couldn't be derived anymore by the TEE since the bootloader would pass a different verified boot key.

It can be obtained from the https://developer.android.com/training/articles/security-key-attestation.html API. The bootloader passes it to the TEE and then the TEE can provide the current key in a way that provides proof it's the current one. The proof is stronger when there's already pairing vs. using Google's included key attestation root. Someone would need to implement an app to do this.

[thestinger]

The weakness of key attestation is that an attacker that had compromised the system (i.e. root access) could exploit either the bootloader or TEE to fake that, not only the bootloader which is the guarantee provided by the key id shown on boot.

[thestinger]

The weakness of key attestation is that an attacker that had compromised the system (i.e. root access) could exploit either the bootloader or TEE to fake that, not only the bootloader which is the guarantee provided by the key id shown on boot.

[mke208]

Understand. Thanks!

[mke208]

Understand. Thanks!

[thestinger]

Also FWIW the key id on Nexus devices was too short... they really need to make it longer, and they should use alphanumeric instead of hex. I mentioned this in the issue I filed, so we'll see what happens for Pixels and 2nd generation Pixels.

[thestinger]

Also FWIW the key id on Nexus devices was too short... they really need to make it longer, and they should use alphanumeric instead of hex. I mentioned this in the issue I filed, so we'll see what happens for Pixels and 2nd generation Pixels.

[thestinger]

It's covered in https://copperhead.co/android/docs/devices.

[thestinger]

It's covered in https://copperhead.co/android/docs/devices.

[thestinger]

Please upgrade to N2G48B.2017.07.06.18.26.24 and try there.

[thestinger]

Please upgrade to N2G48B.2017.07.06.18.26.24 and try there.

[theGrower]

Update did not correct issue. I'll get logs tomorrow.

[theGrower]

Update did not correct issue. I'll get logs tomorrow.

[theGrower]

After enabling Chromium for a different issue, the email is now loading ... I don't understand.

[theGrower]

After enabling Chromium for a different issue, the email is now loading ... I don't understand.

[thestinger]

Chromium provides the WebView. There were previously two copies of Chromium, one for the browser and one for the WebView. There's no longer a redundant copy of it.

[thestinger]

Chromium provides the WebView. There were previously two copies of Chromium, one for the browser and one for the WebView. There's no longer a redundant copy of it.

[theGrower]

I get it, thank you good sir!!!!

[theGrower]

I get it, thank you good sir!!!!

[mke208]

One question, what UID does the WebView run under ? Chromiun UID, separate UID or UID of the process who calls it ?

[mke208]

One question, what UID does the WebView run under ? Chromiun UID, separate UID or UID of the process who calls it ?

[thestinger]

It isn't tied to the Chromium browser. It's a library loaded by processes using the WebView. Providing both from the same apk doesn't change how it works.

Chromium has a sandbox to contain attackers if they gain remote code execution via an exploit so each site instance is rendered by a process in a fresh isolatedProcess service. Most of the code runs in the sandboxes. An isolatedProcess has a unique, ephemeral UID/GID assigned from the range reserved for isolated processes, and they are in the isolated_app SELinux domain (isolated_base_app on CopperheadOS) rather than untrusted_app / untrusted_base_app. Chromium also applies a strict seccomp-bpf filter on top of that as an extra layer of security, so the sandboxed code can't even call open.

CopperheadOS enables the sandbox for the WebView since Android 7.0, which stock Android will be doing with 8.0. Each app using a WebView has a single isolatedProcess. It doesn't split multiple instances of the WebView into separate sandboxes at the moment. If the sandbox isn't enabled, it all runs as the app loading it, since it's just a library.

[thestinger]

It isn't tied to the Chromium browser. It's a library loaded by processes using the WebView. Providing both from the same apk doesn't change how it works.

Chromium has a sandbox to contain attackers if they gain remote code execution via an exploit so each site instance is rendered by a process in a fresh isolatedProcess service. Most of the code runs in the sandboxes. An isolatedProcess has a unique, ephemeral UID/GID assigned from the range reserved for isolated processes, and they are in the isolated_app SELinux domain (isolated_base_app on CopperheadOS) rather than untrusted_app / untrusted_base_app. Chromium also applies a strict seccomp-bpf filter on top of that as an extra layer of security, so the sandboxed code can't even call open.

CopperheadOS enables the sandbox for the WebView since Android 7.0, which stock Android will be doing with 8.0. Each app using a WebView has a single isolatedProcess. It doesn't split multiple instances of the WebView into separate sandboxes at the moment. If the sandbox isn't enabled, it all runs as the app loading it, since it's just a library.

[thestinger]

So without the sandbox enabled, the WebView runs as the UID/GID of the app using it since it's just a library loaded by the app. Since it has the sandbox, it's more complicated than that, but it's not a special case. An app can use isolatedProcess for other services it runs rather than running them with the same privileges as the main app processes and there can be other shared library apks working the same way as the WebView.

[thestinger]

So without the sandbox enabled, the WebView runs as the UID/GID of the app using it since it's just a library loaded by the app. Since it has the sandbox, it's more complicated than that, but it's not a special case. An app can use isolatedProcess for other services it runs rather than running them with the same privileges as the main app processes and there can be other shared library apks working the same way as the WebView.

[mke208]

Yes, i have read about the sandboxing ... I was asking because i am considering the scenario when an app that is firewalled based on UID and not allowed to use the net, can use the webview to send data. Normally it should not.

[mke208]

Yes, i have read about the sandboxing ... I was asking because i am considering the scenario when an app that is firewalled based on UID and not allowed to use the net, can use the webview to send data. Normally it should not.

[thestinger]

isolatedProcess doesn't have network access. It can only access files, the network, etc. indirectly via communication with the app that started it.

[thestinger]

isolatedProcess doesn't have network access. It can only access files, the network, etc. indirectly via communication with the app that started it.

[mke208]

Understand that. Thanks !

[mke208]

Understand that. Thanks !