VpnService: Inconsistent handling of DNS servers when migrating from one TUN device to another [116257079]

Fixed

Bug

[AOSP] assigned

Status Update

No update yet.

Description

to...@strongswan.org

created issue #1

Sep 21, 2018 02:24PM

We've noticed some inconsistent behavior regarding DNS servers when migrating from one TUN device created with VpnService.Builder to another.

As documented (

https://developer.android.com/reference/android/net/VpnService.Builder#addDnsServer(java.net.InetAddress)), if no DNS server is configured the default network's DNS servers should get used. However, when switching from a device without DNS server to one that has servers set and vice-versa there are two issues:

1. If the first VpnService.Builder had no DNS servers assigned and there is a switch to one with DNS servers, the system continues to use the DNS servers from the default network in addition to the ones assigned from the VPN server, resulting in a DNS leak (i.e. there are DNS queries that don't go to the DNS servers received from the VPN server). Actually, the requests to the non-VPN DNS servers bypass the VPN completely, even if the DNS servers' IP addresses match the routes installed via Builder. However, if the first device has DNS servers assigned (different from the ones assigned later), the system only uses the ones assigned to the second device after the switch, so that works correctly.

2. If the first VpnService.Builder has DNS servers assigned and is followed by one that doesn't, instead of falling back to the DNS servers of the default network, the system actually ends up without any DNS servers (i.e. DNS resolution fails afterwards). That's not the case if the first device already had no DNS servers assigned.

Both these issues have been observed on a Pixel 2 with Android 9 (latest security update). The only other device I had available was a Nexus 6 with Android 7.1.1, where *neither* issue was seen.

Comments

jo...@gmail.com <jo...@gmail.com> #2Sep 22, 2018 02:38AM

Agreed, you can download photos via the Google Drive API but this hasn't been incorporated into the Photos API yet...

ma...@google.com <ma...@google.com> #3Sep 24, 2018 11:17AM

Assigned to ma...@google.com.

There's already an issue tracking the missing EXIF data here:

https://issuetracker.google.com/111228390

Regarding the file at original quality - this is something that's on our list and will be addressed soon, please stay tuned. I'll update this bug once we have an update to share.

to...@strongswan.org <to...@strongswan.org> #4Sep 24, 2018 02:23PM

We have just released a new version of the Google Photos Library API that supports now this feature.

You can now use the "d" base URL parameter to download the original photo. See the base URL parameter guide for more details:

https://developers.google.com/photos/library/guides/access-media-items#image-base-urls
Thanks for your patience!

See our release notes for further detail:

https://developers.google.com/photos/library/support/release-notes#2018-07-31

ma...@google.com <ma...@google.com> #5Sep 25, 2018 04:20AM

I've been testing downloading images using the "d" parameter, but the files returned are not the original files that were uploaded. The release note above reads "d download parameter, to download the original image". The link to the developer documentation doesn't say that the "original" image will be downloaded. Please can you confirm if the d parameter should download the original image that was uploaded to the api, or if this behavior has since changed.

ma...@google.com <ma...@google.com> #6Dec 19, 2018 05:33AM

Marked as fixed.

I've tested this again, and the file download is a mutated version of the file uploaded to Photos. If I use the web browser and go to

photos.google.com, when I "Download" a photo it is byte-for-byte identical to the file I uploaded. If I use the API and attempt to get a copy, with the included "d" base URL, the file is mutated. Both some metadata is missing, as well the photo itself is modified (doing a pixel-for-pixel comparison shows subtle differences).

Issue 116257079