On Thu, 07 Jun 2018 23:25:54 +1000, Chris Angelico wrote:
[...]
>> Does the Python web server suffer from that vulnerability? I would be
>> surprised if it were. But it can be induced to crash (an exception, not
>> a seg fault) which is certainly a vulnerability.
>
> "Certainly"? I'm dubious on that. This isn't C, where a segfault usually
> comes after executing duff memory, and therefore it's plausible to
> transform a segfault into a remote code execution exploit.
I just said that I would be surprised if you could get remote code
execution from the Python web server, for exactly the reason you state:
its an exception, not a segfault.
Stop agreeing with me when we're trying to have an argument! *wink*
[...]
> Yes, it's a bug. If someone tries a page size of zero, it'll divide by
> zero and bomb. Great. But how is it a vulnerability? It is a
> properly-handled exception.
Causing a denial of service is a vulnerability.
Security vulnerabilities are not just about remote code execution. Can
remote attackers bring your service down? If so, you are vulnerable to
having remote attackers bring your service down.
Can remote attackers overwhelm your server with so many errors that they
fill your disks with error logs and either stop logging, or crash? Then
you are vulnerable to having remote attackers crash your server, or hide
their tracks by preventing logging.
Can remote attackers induce your server to serve files it shouldn't? Then
you are vulnerable to attacks that leak sensitive or private information.
There's far more to security vulnerabilities than just "oh well, they
can't get a shell or execute code on my server, so it's all cool" *wink*
In this specific case:
> It's slightly different with SimpleHTTPServer, as it fails to properly
> send back the 500. That would be a bug IMO.
There seems to be some weird interaction occurring on my system between
the SimpleHTTPServer, Firefox, and my web proxy, so I may have
misinterpreted the precise nature of the crash. What I initially saw was
that allow the SimpleHTTPServer remained running, it stopped responding
to requests and Firefox would repeatedly respond:
Firefox can't find the server at www.localhost.com
even though the process was still running. But when I tried with a
different browser (links), I don't get that same behaviour. links is
using the web proxy, Firefox isn't, but I'm not quite sure why that makes
a difference.
> Even then, though, all you
> can do is clog the server with unfinished requests - and you can do that
> much more easily by just connecting and being really slow to send data.
> (And I doubt that people are using SimpleHTTPServer in
> security-sensitive contexts anyway.)
Again, you're just repeating what I said in different words. I already
said that *this specific* issue is probably low severity, because people
are unlikely to use SimpleHTTPServer for mission critical services
exposed to the internet.
--
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson
--
https://mail.python.org/mailman/listinfo/python-list
