|
|
Subscribe / Log in / New account

The future of the Python ssl module

The future of the Python ssl module

Posted Jun 5, 2016 23:05 UTC (Sun) by bronson (subscriber, #4806)
In reply to: The future of the Python ssl module by noxxi
Parent article: The future of the Python ssl module

It sounds like noxxi and the Python devs would rather have an almost guaranteed DoS to an extremely unlikely MITM?


to post comments

The future of the Python ssl module

Posted Jun 6, 2016 5:55 UTC (Mon) by noxxi (subscriber, #4994) [Link] (2 responses)

> It sounds like noxxi and the Python devs would rather have an almost guaranteed DoS ...

The code changes do not cause DoS by themselves. The DoS is only caused in specific use cases in specific environment where the software relied on the previous default behavior and where the failure of the software after the update then caused a DoS . In other cases the code simply works as before and in yet other cases it will just break but not cause a DoS.

I don't know what exactly happened in this specific case from Cyberax where the change broke the watchdog and thus the setup of the site. But obviously a software upgrade was done on the system running a business critical application without up-front testing and maybe also without reading about the changes done by the software upgrade in detail. The release notes for Python 2.7.9 clearly stated the behavior changes.

While it is easy to complain about the changes to Python in this case I would recommend to better revise the process of installing untested software updates on critical systems, because you will find similar problems everywhere. Just look at the fallouts from CVE-2014-6321, where Microsoft had trouble to get a stable fix for a remote execution in their SChannel TLS library.

There is a reason that SCADA systems and other critical systems usually don't have the very latest system patches installed. In this environment any kind of software updates needs to be tested and approved by the vendor before they get shipped.

> to an extremely unlikely MITM?

Claiming that MITM is extremly unlikely is like claiming that the change causes an almost guaranteed DoS, i.e. exaggerating and making up "facts". Both MITM and DoS very much depend on the environment where the code is used.

But tools like firesheep have shown how easily MITM can be done (even though firesheep was for plain HTTP only the same thing would work with HTTPS when not validating certificates). And if it is possible and maybe easy too it will be done if the target is attractive. But the thing about MITM in a setup where you don't validate certificates is that you don't even realize that it happened. Thus you will not even realize if the change fixed your broken software, you will only realize if the change broke it.

Given that lots of security bugs are actually used in practice (Shellshock, Heartbleat,...) and cause serious damage I'm very much in favor of fixing such vulnerabilities fast, especially if they are trivially to exploit like this one. And yes, there will probably be collateral damage but there would be damage too if the vulnerability gets not fixed.

The future of the Python ssl module

Posted Jun 10, 2016 1:55 UTC (Fri) by mstone_ (subscriber, #66309) [Link] (1 responses)

sounds like he deployed an update in production without testing it.

The future of the Python ssl module

Posted Jun 16, 2016 17:29 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Actually, we tested it. Our customers' sysadmin hasn't - they simply did a routine "apt-get update" to get actual security fixes.

We also support Ubuntu cloud AMIs that started to include Python changes that broke everything. That was fun to debug and fix...


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds