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
DoS smtpd vulnerability #45138
Comments
Method "collect_incoming_data" of "SMTPChannel" class should stop buffering if received lines are too long (possible Denial-of-Service attacks). |
--- malicious script import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(("127.0.0.1", 8025))
while 1:
s.sendall('x' * 1024) --- proposed smtpd.py patch 124a125
135a137,139
|
Sorry, I realized I've forgotten to reset to zero the bytes counter. 124a125
135a137,140
|
Patch is inline above. RFC2822 says lines MUST be less than 998 bytes long, so this should be fine. What does this do when a line longer than 4096 bytes is found? Does it |
Sorry for replying so late. Modified smtpd.py in attachment. It should be definitively fine for |
I update this bug as GvR requested here: In addition it sets a smaller timeout for asyncore.loop() for permitting |
The patch does not work as Giampaolo intends. If the patch were applied Instead, incrementing linelen in the collect_incoming_data() method I can apply a modified version of this patch against trunk after 2.6 is |
Yes, you're right. I mixed up SMTP with FTP which does not send data on |
Given the title, type and severity shouldn't someone take a look at this? |
The definite (and only?) solution would be to implement 'Message Size Declaration[1]' Service Extension[2]. We can limit the size of commands and text lines, but not the message size as a whole[3]. RFC1870 was created exactly with the purpose of solving DoS issues[4]. [1] RFC 1870 I'm willing to implement a fix (actually, I'm already working on that :-)) --- but I'd make good use of advices since I'm new to this project. The minimalistic fix to this issue would be to implement Message Size Extension alone and apart from subclasses awareness --- without any changes to the interface, not even to allow changes in the default maximum message size [once SMPTServer is fully-RFC1869-compliant changing these values will be straightforward]. A second (extensive!) approach is to implement a complete ESMTPServer. That's a way bigger task though. It would be wise in this case to implement all the standard extensions, plus support (parsing/error handling) to all RFC1869. Any thoughts? NOTE: In my opinion there's no bug, really. All non-extented SMPT servers are vulnerable to resource exhaustion. Maybe we should take this as a feature request not a bug-fix request. |
The attached patch adopts the minimalistic approach described in previous post. It pretends to implement Message Size Extension, defining a maximum message data size to 32M bytes and maximum command length to 512 bytes. In my opinion this is the best way to accomplish a patch to the DoS issue alone. It's still a good idea though to implement full ESMTP support -- I know, I'm repeating myself. Please note this is my first patch. I'm new to Python and even though I made my best to be in conformance with the "standards" and good practices I may have missed something. Please review this patch with clinical eyes. For the records: this work is due to Python Bug Day. It worked to attract another curious developer. :-) This project is really awesome. Congratz you all. My best regards. |
Attaching a more concise patch, as requested by georg.brandl. |
I think data_size_limit and command_size_limit should be class attributes instead of instance attributes. |
Previous patch was incorrect. I'm attaching another one, I'm really sorry. @giampaolo, about making the limits class attributes, it's not a good idea IMHO. According to RFC1869 command sizes can change depending on which Service Extensions are supported. |
size_limits are not class attributes instead of instance attributes, as suggested by giampaolo.rodola. |
AFAICT patch looks ok to me. |
Committed in r86955. Thanks! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: