11

According to:

https://docs.python.org/3/library/http.server.html

Warning http.server is not recommended for production. It only implements basic security checks.

It doesn't state what security vulnerabilities the server is exposed to. I'm a sysadmin and have a dev team that wants to push this to production (My understanding is that they are using that while extending http.server.SimpleHTTPRequestHandler) and a CIO that is giving them the green light. I have no idea what risks there are involved because the documentation doesn't elaborate on details. Can somebody enlighten me as to what security vulnerabilities this product has?

user227415
  • 111
  • 1
  • 3
  • 4
    I havent' checked that server specifically but there's a ton of ways to mess with a server that isn't hardened. Most of them are denial-of-service - things like opening a thousand connections each of which only sends one byte of a request every 110 seconds, or failing to sanity-check request sizes or response ranges - but it's also possible that there could be more severe issues like a way to retrieve files that aren't supposed to be readable or otherwise bypass whatever security features it offers. – CBHacking Feb 19 '20 at 02:15

1 Answers1

6

The problem isn't that there are known security vulnerabilities.

The problem is that there is not really an effort to address less common but critical vulnerabilities.

For example, many web servers will display error messages. Until quite recently, Apache Httpd would include some of the request data in the error pages, which allowed cross-site scripting in default configurations of mod_proxy (CVE-2019-10092), with no way for the application developers to mitigate this threat against the site users.

The major web servers, such as Apache Httpd, Nginx, IIS, and Lighttpd each have hundreds of active contributors (or in IIS's case, a large corporate structure behind it), dozens of core developers who understand security best practices, and a team dedicated specifically to reviewing code for potential vulnerabilities. As you can tell by browsing the CVEs of any of those projects, there are still things that people catch after versions are released.

The developers who write HTTP servers for programming languages are small sub-projects, developing tools to support the main product: The language. There might be a dozen people who have contributed code to that tool, and one or two core developers on that project.

They do not have the resources available to search for vulnerabilities, so while there aren't any known vulnerabilities (or at the very least, it is very bad form here to point out known vulnerabilities that are likely to remain unaddressed), there are most certainly vulnerabilities in it, simply due to the complex nature of HTTP servers.

Some of these vulnerabilities might be extremely critical, such as allowing an attacker to have complete control over your server, including executing arbitrary code with a privileged account. Such a vulnerability might not exist, but without a thorough code review—and with the large, red-boxed warning at the top of Python's documentation page—it is plausible that such a vulnerability might exist.

In your specific case, the CIO signed off on it.

It is the CIO's responsibility to ensure that risk assessments are done. As the sysadmin, it's your job to execute the company's officers' instructions, and your responsibility to ensure that the officers have the information they need to be able to make informed decisions.

Because of the boundary in responsibilities, the pushback that I would do is ask to see the risk assessment. If the risk assessment doesn't include a very high probability (due to automated tools quickly finding the vulnerable server in hours) that the server gets infected with malware and used as a Command and Control repeater node for a bot farm, offer to help them make a realistic risk assessment.

Ghedipunk
  • 5,766
  • 2
  • 23
  • 34
  • So overall, the issue is not that the server is insecure in any particular way, just that it's less heavily audited than typical web servers? That doesn't seem to correspond with a big red banner and your assesment of "a very high probability that the server gets infected with malware". – Stack Tracer Feb 25 '20 at 16:32
  • @StackTracer; Web servers typically sit directly exposed to the public internet, and are not trivial applications. If there is _anything_ less than the most heavy security auditing, then it warrants big red warnings and people telling you to expect your server to be pwned within hours. – Ghedipunk Feb 26 '20 at 03:58
  • Interesting assesment. I would generally think that due to the significantly decreased complexity of a web server like http.server vs. something massive like apache, the amount of code (and thus, size of the attack surface) is significantly reduced, and thus I'd consider http.server to be significantly less likely to be pwned. (along with python being a high-level language, and therefore not vulnerable to many of the issues that plague lower level languages). – Stack Tracer Feb 27 '20 at 02:58