geoip.ubuntu.com does not utilize HTTPS

Can you elaborate on what an adversary might do with this connection?

The name itself will be leaked via DNS requests regardless of TLS use.
The name itself may be leaked via SNI headers in a hypothetical HTTPS connection.

I'm not yet familiar with the data actually transferred once connected, but my wildest speculation suggests that it's going to consist of e.g. a User-agent header from the client and the server's best guess of geographical area for the connecting IP address. It's hard to see what an adversary of even immense power could do with any information from this service.

It's also hard to see what an adversary would do if modifying the data in-flight -- force an inconvenient time display in the menu bar perhaps?

Thanks

Exactly. Say I am the NSA and you are connected to Tor. I know your EMAIL user agent like Thunderbird is leaking data in your mail header, like Time Zone data. I know you are connected to Tor and that I want to associate your IP to your email. I fiddle your Time Zone response data to something esoteric, check all the emails that came in over all Tor connections, and associate you with that connection. Yes.

There are even more things you can do as well, like forcing an ETAG or Last-Modified header in order to track the client as it switched from one network to another, eg laptop moved from one insecure network to another.

Further, there are surely unknown parsing vulnerabilities in the response data that you will only find out later. HTTPS , especially with HSTS and HPKP makes abusing such issues much harder.

Let's Encrypt Everything with HTTPS. Unencrypted HTTP is dead.

"""
$ curl -s 'http://geoip.ubuntu.com' -D - | egrep '^(Last|ETag)'
Last-Modified: Wed, 07 Sep 2011 05:58:25 GMT
ETag: "228049-4-4ac53a1e14240"
"""

References:

https://trac.torproject.org/projects/tor/ticket/6314

https://www.chromium.org/Home/chromium-security/client-identification-mechanisms#TOC-Cache-metadata:-ETag-and-Last-Modified

https://mortoray.com/2015/05/11/how-http-cache-headers-betray-your-privacy/

https://letsencrypt.org/

So, also, ummm yeah, you're also running and end-of-life and insecure version of ubuntu there too dude. ubuntu 13.04 (saucy) is NOT getting any security updates. Should someone exploit it remotely to make that point? ;)

Ubuntu 13.10 EOL was July 2014.

You're SSH also appears exposed to Internet and vulnerable to Logjam, which is exploitable by NSA.

You're leaked inode number: 2261065

Your SSH support bad crypto:

arcfour
arcfour128
arcfour256

Your SSH support bad CBC mode:

  3des-cbc
  aes128-cbc
  aes192-cbc
  aes256-cbc
  blowfish-cbc
  cast128-cbc
  <email address hidden>

Your SSH support weak MAC:

  hmac-md5
  hmac-md5-96
  <email address hidden>
  <email address hidden>
  hmac-sha1-96
  <email address hidden>

Any update to this bug? Seems that it would be adviseable to make the change to https for any services possible. The less unencrypted traffic over the web, the better.

@jim no the ubuntu security team also did not respond regarding this issue. unfortunately, it is actually being abused by the great firewall of china to spy on ubuntu users within the border of china. from what we can tell, the ubuntu security team does not take nation state level issues very seriously, which is unfortunate, since google is one of the largest commercial users of ubuntu distro and they are the main target of nation states.

I subscribed security team, it is unlikely that they get such messages if not subscribed :)

You can update to an alternate provider via:

gsettings set com.ubuntu.geoip geoip-url https://freegeoip.net/xml/

and verify the setting via:

gsettings get com.ubuntu.geoip geoip-url

but I have not done extensive testing to see if this breaks anything. Assistance on this would be appreciated.

You can either use the freegeoip service or use its code to host an instance yourself. I do not mean to vouch for their service in any way.

To reset the value to the ubuntu default:

gsettings reset com.ubuntu.geoip geoip-url

Using the:

$ gsettings set com.ubuntu.geoip geoip-url https://freegeoip.net/xml/

Appears to work well enough after initial testing.

1) $ gsettings set com.canonical.indicator.datetime show-auto-detected-location true
shows my correct location

2) apt install geoclue-examples
   and then geoclue-test-gui
   . . . seems to show correct information, as well.

The freegeoip service appears to be well-maintained. Perhaps this is a service that canonical / ubuntu could move to / could support, as well.

It appears as though the servers may have been updated to also serve this over https (previously, https didn't work at the Ubuntu geoip url), but the default value for desktops is to use the http value, and the defaults should be updated

Current values:
$ gsettings reset com.ubuntu.geoip geoip-url
$ gsettings get com.ubuntu.geoip geoip-url
'http://geoip.ubuntu.com/lookup'

Should show:
$ gsettings reset com.ubuntu.geoip geoip-url
$ gsettings get com.ubuntu.geoip geoip-url
'https://geoip.ubuntu.com/lookup'

This bug was fixed in the package ubuntu-geoip - 1.0.2+18.04.20180223-0ubuntu1

---------------
ubuntu-geoip (1.0.2+18.04.20180223-0ubuntu1) bionic; urgency=medium

  * Use https for geoip.ubuntu.com (LP: #1617535)

 -- Jeremy Bicha <email address hidden> Fri, 23 Feb 2018 17:23:36 +0000

Include associated patch for Artful. This package should be updated before packages for Trusty and Xenial, although I'm attaching all three patches at more or less the same time.

Include patch to set https geoip url for Xenial. Package should be updated after the related Artful package, but before the associated Trusty package.

Include associated patch to fix this for Trusty. Please update package after associated packages for Artful and Xenial.

There is still a need to figure out a testcase here before the SRU can be uploaded

Unsubscribing the Ubuntu Sponsors Team for now, due to Sebastien's comment that more work needs to be done.

Please resubscribe the Sponsors Team once adequate tests have been added.

Thank you.

Adding test case here:

1) Install patches / patched package
2) Confirm that the 'geoip url' is set to a correct 'https' value, and that this value is set as the default:
   `$ gsettings get com.ubuntu.geoip geoip-url` should display `https://geoip.ubuntu.com/lookup`
   `$ gsettings reset com.ubuntu.geoip geoip-url && gsettings get com.ubuntu.geoip geoip-url` should continue to display `https://geoip.ubuntu.com/lookup` (this will confirm that the `https` value is set as the default.
3) Confirm that the the correct location is being retrieved by the Ubuntu geoip service:
   apt install geoclue-examples
   and then geoclue-test-gui
   . . . should show correct location information.

If additional test cases / test case information is needed, please let me know. Thanks.

Might anyone be able to clarify what kinds of additional test cases (if any) are needed? If so, I would appreciate it. I'm making an attempt to be helpful in fixing this bug, but am a bit new to Canonical's internal processes in terms of what they expect to test / resolve these kinds of bugs. Any additional info / resources would be helpful. Thanks,

Sorry for the delay, I didn't see the previous comments. I've sponsored to Xenial now, Artful is not supported anymore so marking that one as wontfix. Unsure it makes sense to do an upload to trusty at this point

Hello xtsbdu3reyrbrmroezob, or anyone else affected,

Accepted ubuntu-geoip into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubuntu-geoip/1.0.2+14.04.20131125-0ubuntu2.16.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hi All - I can test this on Xenial tomorrow (Jan 23). I'll report back after testing.

Thanks to Brian for getting the package into xenial-proposed.

$ apt-cache policy geoclue-ubuntu-geoip
geoclue-ubuntu-geoip:
  Installed: 1.0.2+14.04.20131125-0ubuntu2.16.04.1
  Candidate: 1.0.2+14.04.20131125-0ubuntu2.16.04.1

Test #1 - Passed - URL includes https on first check
$ gsettings get com.ubuntu.geoip geoip-url
'https://geoip.ubuntu.com/lookup'

Test #2 - Passed - Reset the gsettings key & the URL value still includes https
$ gsettings reset com.ubuntu.geoip geoip-url && gsettings get com.ubuntu.geoip geoip-url
'https://geoip.ubuntu.com/lookup'

Test #3 - Passed - geoclue-examples application shows my correct location information

FWIW, we have the patch for Trusty, and I can test it, but I know that Trusty will reach EOL in less than four months. I will leave it at your discretion as to whether to go forward with the update for Trusty.

Also, I thanked Brian for getting the Xenial update into Proposed, but forgot to thank Sebastian for his help, too. Thanks to both. : )

This bug was fixed in the package ubuntu-geoip - 1.0.2+14.04.20131125-0ubuntu2.16.04.1

---------------
ubuntu-geoip (1.0.2+14.04.20131125-0ubuntu2.16.04.1) xenial; urgency=medium

  [ Jim Campbell ]
  * Use https for geoip.ubuntu.com/lookup URL (LP: #1617535)

 -- Jim Campbell <email address hidden> Fri, 16 Mar 2018 19:26:42 +0000

The verification of the Stable Release Update for ubuntu-geoip has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.