As you might know, with PEP 476, since Python 3.5 (backported to 3.4.3 and 2.7.9) tls certificates are now checked for their validity.
Lack of validation leaves software exposed to mitm, so I think it's fairly uncontroversial to think of the update 2.7.8 -> 2.7.9 as a security update.
Recently I found myself using my old laptop, running Ubuntu LTS instead of the latest and greatest. After running updates and setting up the environment to work on some python code, I realized that the version for the python2 interpreter seemed suspiciously low: 2.7.5-5ubuntu3
You can check yourself the version online:
latest python2.7 on latest ubuntu (as of 26th December 2015) is 2.7.9-1
latest python2.7 on latest ubuntu lts (as of 26th December 2015) 2.7.5-5ubuntu3
This doesn't necessarily means that it doesn't ship the 2.7.9 changes, because they could've been backported (though I find it suspicious, due to the huge change in the ssl module, I'd expect it easier to adopt 2.7.9 wholesale rather than backporting the patches)... so I tried to open up a page with a certificate that's not commonly accepted (e.g. https://cacert.org ) and, to my dismay, no exception was raised.
For comparison, with a newer Python:
>>> urlopen('https://cacert.org')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
return opener.open(url)
[...SNIP...]
File "/usr/lib/python2.7/ssl.py", line 808, in do_handshake
self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)
It has now been more than 1 year since Python 2.7.9 has been released, and both Ubuntu 14.04.2 and 14.04.3 have been released in the meanwhile, so if it hasn't been backported, it's not because they were waiting for a dot-release of the LTS.
An example of how things might be affected by this change: At my previous job, I found an internal script that was scheduled to connect and authenticate to an internal https-only website to report some information, such internal website relied on an internal root certificate. The script didn't fail, even if the root CA was not available to it, only thanks to the lack of this check. The credentials were stored safely on disk, but (as risky as it would've been to do it in a work environment) being on the same network it could've been possible to do a mitm attack to steal these credentials.
This is interesting because updating to 2.7.9 would both solve the potential security issue with that script, and make the script stop working until fixed. I thus thought that an explanation for why this hasn't been backported to Ubuntu LTS might be the risk in breaking existing code, but I'm not persuaded.
While I'm at it, here's the code to fix such broken code, by doing certificate pinning (actually only the CA is pinned) for the benefit of people who might stumble on this, since it's really trivial but there are not a lot of examples around:
import ssl as tls
try:
from urllib.request import urlopen
except ImportError:
from urllib import urlopen
# this is the certificate in binary form, taken from http://www.cacert.org/certs/root.der
cert = '0\x82\x07=0\x82\x05%\xa0\x03\x02\x01\x02\x02\x01\x000\r\x06\t*\x86H\x86\xf7\r\x01\x01\x04\x05\x000y1\x100\x0e\x06\x03U\x04\n\x13\x07Root CA1\x1e0\x1c\x06\x03U\x04\x0b\x13\x15http://www.cacert.org1"0 \x06\x03U\x04\x03\x13\x19CA Cert Signing Authority1!0\x1f\x06\t*\x86H\x86\xf7\r\x01\t\x01\x16\[email protected]\x1e\x17\r030330122949Z\x17\r330329122949Z0y1\x100\x0e\x06\x03U\x04\n\x13\x07Root CA1\x1e0\x1c\x06\x03U\x04\x0b\x13\x15http://www.cacert.org1"0 \x06\x03U\x04\x03\x13\x19CA Cert Signing Authority1!0\x1f\x06\t*\x86H\x86\xf7\r\x01\t\x01\x16\[email protected]\x82\x02"0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x01\x05\x00\x03\x82\x02\x0f\x000\x82\x02\n\x02\x82\x02\x01\x00\xce"\xc0\xe2F}\xec6(\x07P\x96\xf2\xa03@\x8cK\xf1;f?1\xe5k\x026\xdb\xd6|\xf6\xf1\x88\x8fNw6\x05A\x95\xf9\t\xf0\x12\xcfF\x86s`\xb7n~\xe8\xc0Xd\xae\xcd\xb0\xadE\x17\x0cc\xfag\n\xe8\xd6\xd2\xbf>\xe7\x98\xc4\xf0L\xfa\xe0\x03\xbb5]l!\xde\x9e \xd9\xba\xcdf27r\xfa\xf7\x08\xf5\xc7\xcdX\xc9\x8e\xe7\x0e^\xea>\xfe\x1c\xa1\x14\n\x15l\x86\x84[df*z\xa9KSy\xf5\x88\xa2{\xee/\na+\x8d\xb2~MV\xa5\x13\xec\xea\xda\x92\x9e\xacDA\x1eX`e\x05f\xf8\xc0D\xbd\xcb\x94\xf7B~\x0b\xf7eh\x98Q\x05\xf0\xf3\x05\x91\x04\x1d\x1b\x17\x82\xec\xc8W\xbb\xc3kz\x88\xf1\xb0r\xcc%[ \x91\xec\x16\x02\x12\x8f2\xe9\x17\x18H\xd0\xc7\x05.\x020B\xb8%\x9c\x05k?\xaa:\xa7\xebSH\xf7\xe8\xd2\xb6\x07\x98\xdc\x1b\xc64\x7f\x7f\xc9\x1c\x82z\x05X+\x08[\xf38\xa2\xab\x17]f\xc9\x98\xd7\x9e\x10\x8b\xa2\xd2\xddt\x9a\xf7q\x0cr`\xdf\xcdo\x983\x9d\x964v>$z\x92\xb0\x0e\x95\x1eo\xe6\xa0E8G\xaa\xd7A\xedJ\xb7\x12\xf6\xd7\x1b\x83\x8a\x0f.\xd8\t\xb6Y\xd7\xaa\x04\xff\xd2\x93}h.\xdd\x8bK\xabX\xba/\x8d\xea\x95\xa7\xa0\xc3T\x89\xa5\xfb\xdb\x8bQ"\x9d\xb2\xc3\xbe\x11\xbe,\x91\x86\x8b\x96x\xad \xd3\x8a/\x1a?\xc6\xd0Qe\x87!\xb1\x19\x01e\x7fE\x1c\x87\xf5|\xd0ALO)\x98!\xfd3\x1fu\x0c\x04Q\xfa\x19w\xdb\xd4\x14\x1c\xee\x81\xc3\x1d\xf5\x98\xb7i\x06\x91"\xdd\x00P\xcc\x811\xac\x12\x07{8\xdah[\xe6+\xd4~\xc9_\xad\xe8\xebrL\xf3\x01\xe5K \xbf\x9a\xa6W\xca\x91\x00\x01\x8b\xa1u!7\xb5c\rg>FOp g\xce\xc5\xd6Y\xdb\x02\xe0\xf0\xd2\xcb\xcd\xbab\xb7\x90A\xe8\xdd \xe4)\xbcd)B\xc8"\xdcx\x9a\xffC\xec\x98\x1b\tQKZZ\xc2q\xf1\xc4\xcbs\xa9\xe5\xa1\x0b\x02\x03\x01\x00\x01\xa3\x82\x01\xce0\x82\x01\xca0\x1d\x06\x03U\x1d\x0e\x04\x16\x04\x14\x16\xb52\x1b\xd4\xc7\xf3\xe0\xe6\x8e\xf3\xbd\xd2\xb0:\xee\xb29\x18\xd10\x81\xa3\x06\x03U\x1d#\x04\x81\x9b0\x81\x98\x80\x14\x16\xb52\x1b\xd4\xc7\xf3\xe0\xe6\x8e\xf3\xbd\xd2\xb0:\xee\xb29\x18\xd1\xa1}\xa4{0y1\x100\x0e\x06\x03U\x04\n\x13\x07Root CA1\x1e0\x1c\x06\x03U\x04\x0b\x13\x15http://www.cacert.org1"0 \x06\x03U\x04\x03\x13\x19CA Cert Signing Authority1!0\x1f\x06\t*\x86H\x86\xf7\r\x01\t\x01\x16\[email protected]\x82\x01\x000\x0f\x06\x03U\x1d\x13\x01\x01\xff\x04\x050\x03\x01\x01\xff02\x06\x03U\x1d\x1f\x04+0)0\'\xa0%\xa0#\x86!https://www.cacert.org/revoke.crl00\x06\t`\x86H\x01\x86\xf8B\x01\x04\x04#\x16!https://www.cacert.org/revoke.crl04\x06\t`\x86H\x01\x86\xf8B\x01\x08\x04\'\x16%http://www.cacert.org/index.php?id=100V\x06\t`\x86H\x01\x86\xf8B\x01\r\x04I\x16GTo get your own certificate for FREE head over to http://www.cacert.org0\r\x06\t*\x86H\x86\xf7\r\x01\x01\x04\x05\x00\x03\x82\x02\x01\x00(\xc7\xee\x9c\x82\x02\xba\\\x80\x12\xca5\n\x1d\x81o\x89j\x99\xcc\xf2h\x0f\x7f\xa7\xe1\x8dX\x95>\xbd\xf2\x06\xc3\x90Z\xac\xb5`\xf6\x99C\x01\xa3\x88p\x9c\x9db\x9d\xa4\x87\xafgX\r06;\xe6\xadH\xd3\xcbt\x02\x86q>\xe2+\x03h\xf14b@F;S\xea(\xf4\xac\xfbf\x95S\x8aM]\xfd;\xd9`\xd7\xcayi;\xb1e\x92\xa6\xc6\x81\x82\\\x9c\xcd\xebM\x01\x8a\xa5\xdf\x11U\xaa\x15\xca\x1f7\xc0\x82\x98pa\xdbj|\x96\xa3\x8e.T>O!\xa9\x90\xef\xdc\x82\xbf\xdc\xe8E\xadM\x90s\x08<\x94e\xb0\x04\x99v\x7f\xe2\xbc\xc2j\x15\xaa\x97\x047$\xd8\x1e\x94Nm\x0eQ\xbe\xd6\xc4\x8f\xca\x96m\xf7C\xdf\xe80e\';{\xbbCCc\xc4C\xf7\xb2\xech\xcc\xe1\x19\x8e"\xfb\x98\xe1{Z>\x017;\x8b\x08\xb0\xa2\xf3\x95N\x1a\xcb\x9b\xcd\x9a\xb1\xdb\xb2p\xf0-J\xdb\xd8\xb0\xe3oEH3\x12\xff\xfe<2*T\xf7\xc4\xf7\x8a\xf0\x88#\xc2G\xfedzq\xc0\xd1\x1e\xa6c\xb0\x07~\xa4/\xd3\x01\x8f\xdc\x9f+\xb6\xc6\x08\xa9\x0f\x93H%\xfc\x12\xfd\x9fB\xdc\xf3\xc4>\xf6W\xb0\xd7\xddi\xd1\x06w4\nK\xd2\xca\xa0\xff\x1c\xc6\x8c\xc9\x16\xbe\xc4\xcc27hs_\x08\xfbQ\xf7IS6\x05\n\x95\x02L\xf2y\x1a\x10\xf6\xd8:u\x9c\xf3\x1d\xf1\xa2\rpg\x86\x1b\xb3\x16\xf5/\xe5\xa4\xeby\x86\xf9=\x0b\xc2s\x0b\xa5\x99\xaco\xfcg\xb8\xe5/\x0b\xa6\x18$\x8d{\xd1H5)\x18@\xac\x93`\xe1\x96\x86P\xb4zY\xd8\x8f!\x0b\x9f\xcf\x82\x91\xc6;\xbfk\xdc\x07\x91\xb9\x97V#\xaa\xb6l\x94\xc6H\x06<\xe4\xceN\xaa\xe4\xf6/\t\xdcSo.\xfct\xeb:c\x99\xc2\xa6\xac\x89\xbc\xa7\xb2D\xa0\r\x8a\x10\xe3l\xf2$\xcb\xfa\x9b\x9fpG.\xde\x14\x8b\xd4\xb2 \t\x96\xa2d\xf1$\x1c\xdc\xa15\x9c\x15\xb2\xd4\xbcU.}\x06\xf5\x9c\x0eU\xf4Z\xd6\x93\xdav\xad%sL\xc5C'
ctx = tls.create_default_context(cadata=cert)
urlopen('https://cacert.org', context=ctx) # success
Whatever the reason for not shipping this security fix, there's often expectation that (barring 0 days and newly discovered vulnerabilities) having a system of a supported OS version, with all of the system updates installed (and kept up-to-date subsequently) gives you a secure foundation over which to build a system (which will then be made insecure with misconfigurations and custom code).
I was a bit unsure if I should ask this over unix.stackexchange.com or somewhere else, anyhow I tried to have a look for documentation on the policy used by the Ubuntu maintainers [1] [2] [3], and I don't see anywhere that could explain why some fixes might not qualify to be backported. OTOH security support means:
[they] provide security updates for supported software in the Ubuntu distribution.
Nowhere it's written that such updates are complete and exhaustively cover every security issue known by the maintainers. Ok, FOSS software often/always has the "No warranty" clause/disclaimer, but I'm not concerned about that.
I'm concerned with the mismatching expectations that IT professionals and the world at large have over security updates, and what can actually be provided: After all, not every software project has different releases still supported, and if it's still in active development, it might not be feasible to backport such fixes to older versions (ok, it might be argued that such software shouldn't belong in the Ubuntu main repositories). Sometimes security issues might be fixed upstream, without the developers realizing they were security issues in the first place, and so no one will realize the need for backporting these. And this is assuming that the maintainers are infallible beings that won't commit mistakes.
There's a question that asks about a similar problem but from a different angle: PCI compliance. I'd expect such a standard to be both more-strict than best practices for normal server/workstation deployments, and also not as comprehensive as needed to cover every possible case (after all, standards are formalized only after enough people take notice). So for PCI compliance that might be only needed to "tick a checkbox", but it'd be worrying if even to follow best practices it wasn't enough just to run the system updates, but we'd need to also keep track with upstream for every single piece of software running on a system.
OTOH, if we truly have to take ownership of all of this, it would force us in the direction of having less to deal with, a smaller attack surface and fewer moving parts... Maybe scrapping Linux or a full-fledged OS altogether and only run Unikernels on server...
So, what is/could be the rationale for not choosing to backport such fixes? Is it documented?
PS: After writing this, I found this other stackexchange question
The upstream version of Python 2.7 in Ubuntu 14.04 will always be 2.7.6.
This is a bit at odds with my understanding of the wiki, since potentially Ubuntu could ship 2.7.9 for Trusty. The answerer anyhow doesn't seem to be affiliated with Canonical/Ubuntu, he also writes:
Since 2.7.9 will be part of Ubuntu 15.04, I'd expect an update around the time 14.04.2 releases, if ever. The corresponding Launchpad bug is as yet unassigned.
(emphasis mine)
So, with 14.04.2 nothing obviously changed. One user on Launchpad mentions:
As for backporting to older releases I don't know, but it should be possible to add a request once the package has landed in Vivid.
I know that there's a process to request normal backports in Debian/Ubuntu, but that shouldn't apply for security updates.
