Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Serve forever throws exception on connection bashing #100

Closed
giampaolo opened this issue May 28, 2014 · 11 comments
Closed

Serve forever throws exception on connection bashing #100

giampaolo opened this issue May 28, 2014 · 11 comments
Labels
bug Component-Library imported imported from old googlecode site and very likely outdated OpSys-UNIX Priority-High Security

Comments

@giampaolo
Copy link
Owner

From bne...@gmail.com on February 27, 2009 21:13:09

What steps will reproduce the problem?  
1. Start a simple ftp sever, like the example (shareftp in my case)
2. Bash it with nmap
3. Keep bashing it till it throws an exception. 

What is the expected output?  


What do you see instead?  
I would have expected it to be able to handle that, but maybe there should
be an option that says: "robustly serve" ?

What version of pyftpdlib are you using? On what operating system? Which
Python version?
Python 2.5.4
pyftpdlib 0.5.1 

Please provide any additional information below.  
192.168.1.35:38360 ==> 220 pyftpdlib 0.5.1 ready.
[]@192.168.1.35:38360 Disconnected.
[]192.168.1.35:38362 Connected.
192.168.1.35:38362 ==> 220 pyftpdlib 0.5.1 ready.
[]@192.168.1.35:38362 Disconnected.
[]192.168.1.35:38364 Connected.
192.168.1.35:38364 ==> 220 pyftpdlib 0.5.1 ready.
[]@192.168.1.35:38364 Disconnected.
[]192.168.1.35:38366 Connected.
192.168.1.35:38366 ==> 220 pyftpdlib 0.5.1 ready.
[]@192.168.1.35:38366 Disconnected.
[]192.168.1.35:38368 Connected.
192.168.1.35:38368 ==> 220 pyftpdlib 0.5.1 ready.
[]@192.168.1.35:38368 Disconnected.
[]192.168.1.35:38370 Connected.
Traceback (most recent call last):
  File "/home/bram/bin/shareftp", line 152, in <module>
    sys.exit(main(sys.argv))
  File "/home/bram/bin/shareftp", line 142, in main
    ftpd.serve_forever()
  File "/var/lib/python-support/python2.5/pyftpdlib/ftpserver.py", line
3106, in serve_forever
    poll_fun(timeout, map)
  File "/usr/lib/python2.5/asyncore.py", line 132, in poll
    read(obj)
  File "/usr/lib/python2.5/asyncore.py", line 72, in read
    obj.handle_error()
  File "/usr/lib/python2.5/asyncore.py", line 68, in read
    obj.handle_read_event()
  File "/usr/lib/python2.5/asyncore.py", line 384, in handle_read_event
    self.handle_accept()
  File "/var/lib/python-support/python2.5/pyftpdlib/ftpserver.py", line
3130, in handle_accept
    handler = self.handler(sock_obj, self)
  File "/var/lib/python-support/python2.5/pyftpdlib/ftpserver.py", line
1607, in __init__
    self.remote_ip, self.remote_port = self.socket.getpeername()[:2]
  File "<string>", line 1, in getpeername
socket.error: (107, 'Transport endpoint is not connected')

Original issue: http://code.google.com/p/pyftpdlib/issues/detail?id=100
@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on February 27, 2009 14:18:16

I identified the problem.
It's a race condition occurring since the connection is closing before we can get the
peername.
Putting the getpeername() call in a try/except clause looking for ENOTCONN should
solve the problem.

Unfortunately I've not been able to figure out how can I bash the ftpd with nmap.
Could you tell me how can I do that?

Status: Accepted

@giampaolo
Copy link
Owner Author

From bne...@gmail.com on February 28, 2009 04:12:32

I didn't automate it, just running nmap multiple times will work, but here is how you
can do it from a linux console with nmap installed and a server running on port 9000:
for i in {1..20};do nmap -sT -p 9000 localhost;done

-p = Port
-sT = connect scan

Hope it helps.

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on February 28, 2009 04:33:03

Ok, I've been able to reproduce the issue.
It's quite important since the server shuts down irreparably (DoS).
Bumping up priority.

Status: Started
Labels: -Priority-Medium Priority-High Security

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on February 28, 2009 08:04:21

Fixed as r543 .
For now you can get the latest pyftpdlib revision via svn and use that in your
shareftp project.
Thanks a lot for your report.

Status: Finished

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on March 02, 2009 17:41:03

Labels: Version-0.5.1 Milestone-0.5.2

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on April 02, 2009 08:53:55

Labels: -OpSys-All

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on April 02, 2009 11:32:41

Labels: OpSys-UNIX

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on April 04, 2009 06:42:45

Labels: Crash

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on August 29, 2009 10:34:02

Status: FixedInSVN

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on September 13, 2009 13:56:15

Status: Fixed

@giampaolo
Copy link
Owner Author

From billiej...@gmail.com on September 13, 2009 14:01:52

This is now fixed and included as part of 0.5.2 version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Component-Library imported imported from old googlecode site and very likely outdated OpSys-UNIX Priority-High Security
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@giampaolo