Slowloris DoS Vulnerability #1266

Closed
LeoTindall opened this Issue Dec 4, 2014 · 8 comments

Comments

4 participants
@LeoTindall
Contributor

LeoTindall commented Dec 4, 2014

The Flask development is vulnerable to RSnake's SlowLoris single-machine denial of service attack. I tested Flask on Ubuntu 14.04 with a Raspberry Pi Model B running Raspbian as the attacker. The DoS succeeded in under a second. This is generally caused by restrictive threading limits, see http://ha.ckers.org/slowloris/

Unfortunately, unlike many webservers, Flask does not seem to recover gracefully when the attack ends, instead throwing broken pipe errors and no longer serving pages until restarted. This affects both debug and normal modes.

Edit: Looks like this was discovered previously and is mentioned here: http://librelist.com/browser//flask/2014/9/2/fwd-dos-via-socketserver/

@davidism

This comment has been minimized.

Show comment Hide comment
@davidism

davidism Dec 4, 2014

Owner

Don't use the development server in production. Use a real application server (uwsgi, gunicorn, etc.) and web server (nginx, apache, etc.).

In fact, the thread you linked goes on to strongly say exactly that.

Owner

davidism commented Dec 4, 2014

Don't use the development server in production. Use a real application server (uwsgi, gunicorn, etc.) and web server (nginx, apache, etc.).

In fact, the thread you linked goes on to strongly say exactly that.

@LeoTindall

This comment has been minimized.

Show comment Hide comment
@LeoTindall

LeoTindall Dec 4, 2014

Contributor

I've seen it in use several times in production. I agree completely that people shouldn't, but they do, so it's still a problem.

Contributor

LeoTindall commented Dec 4, 2014

I've seen it in use several times in production. I agree completely that people shouldn't, but they do, so it's still a problem.

@davidism

This comment has been minimized.

Show comment Hide comment
@davidism

davidism Dec 4, 2014

Owner

I don't speak for the devs, but I doubt you're going to get anywhere on this one with that sort of argument. The answer is that the problem is solved by not using the dev server in production.

Owner

davidism commented Dec 4, 2014

I don't speak for the devs, but I doubt you're going to get anywhere on this one with that sort of argument. The answer is that the problem is solved by not using the dev server in production.

@LeoTindall

This comment has been minimized.

Show comment Hide comment
@LeoTindall

LeoTindall Dec 4, 2014

Contributor

Fair enough. I'm just pointing out what I found, if/when I get around to fixing it I'll submit a pull request.

Contributor

LeoTindall commented Dec 4, 2014

Fair enough. I'm just pointing out what I found, if/when I get around to fixing it I'll submit a pull request.

@robertlagrant

This comment has been minimized.

Show comment Hide comment
@robertlagrant

robertlagrant Dec 4, 2014

Also look at Waitress. Big fan.

Also look at Waitress. Big fan.

@untitaker

This comment has been minimized.

Show comment Hide comment
@untitaker

untitaker Dec 4, 2014

Owner

Flask's server can handle only one request at a time (unless multithreading or multiprocessing is enabled), so no attacks are necessary in multi-user usage to get it down to its knees. Maybe you could try it with those options enabled, but even then I don't really see it as a problem.

Owner

untitaker commented Dec 4, 2014

Flask's server can handle only one request at a time (unless multithreading or multiprocessing is enabled), so no attacks are necessary in multi-user usage to get it down to its knees. Maybe you could try it with those options enabled, but even then I don't really see it as a problem.

@LeoTindall

This comment has been minimized.

Show comment Hide comment
@LeoTindall

LeoTindall Dec 4, 2014

Contributor

The attack remains effective on the multithreaded version, though it does take longer to work. I would suggest making it more explicit in the documentation that a) the server is vulnerable and b) that it shouldn't be used in production.

Contributor

LeoTindall commented Dec 4, 2014

The attack remains effective on the multithreaded version, though it does take longer to work. I would suggest making it more explicit in the documentation that a) the server is vulnerable and b) that it shouldn't be used in production.

@untitaker

This comment has been minimized.

Show comment Hide comment
@untitaker

untitaker Dec 4, 2014

Owner

Yes, see mitsuhiko#1170 for that.

Owner

untitaker commented Dec 4, 2014

Yes, see mitsuhiko#1170 for that.

@untitaker untitaker closed this Dec 4, 2014

@untitaker untitaker referenced this issue Dec 4, 2014

Merged

Rewrite deployment docs #1170

3 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment