homepage

This bug is similar to #16037 and a modified copy of #16038.
The poplib module doesn't limit the amount of read data in its call to readline(). An erroneous or malicious POP3 server can trick the poplib module to consume large amounts of memory.
Suggestion:
The poplib module should be modified to use limited readline() with _MAXLINE like the httplib module.

RFC 1939 says:
 Responses in the POP3 consist of a status indicator and a keyword
 possibly followed by additional information. All responses are
 terminated by a CRLF pair. Responses may be up to 512 characters
 long, including the terminating CRLF.
It doesn't say anything about the length of a line in a multi-line response. It's reasonable to belief that 512 octets are valid, too. We could quadruple the limit to 2048 in order to be safe.

CVE-2013-1752 Unbound readline() DoS vulnerabilities in Python stdlib

Added a functionality that raises error_proto('line too long') if we read over _MAXLINE characters. Defaults _MAXLINE to 2048. The patch is written on top of 2.7

Not blocking 2.7.4 as discussed on mailing list.

Attached a patch for 2.6. 
Due to how tests are in 2.6, this adds one more test case with evil server, which basically just returns too long lines.

Looks good, although only the POP3 exception is actually tested. The POP3_SSL exception isn't tested. Any chance you could add a test for that (obviously, only if `import ssl` succeeds)?

Added a test for SSL, if SSL is available

New changeset 7214e3324a45 by Barry Warsaw in branch '2.6':
- Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
http://hg.python.org/cpython/rev/7214e3324a45 

> New changeset 7214e3324a45 by Barry Warsaw in branch '2.6':
> - Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
> http://hg.python.org/cpython/rev/7214e3324a45
> ...
> --- a/Misc/NEWS
> +++ b/Misc/NEWS
> ...
> +- Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
> + prevent readline() calls from consuming too much member.
Maybe s/member/memory/ ?

On Sep 30, 2013, at 08:41 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>
>Arfrever Frehtes Taifersar Arahesis added the comment:
>
>> New changeset 7214e3324a45 by Barry Warsaw in branch '2.6':
>> - Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
>> http://hg.python.org/cpython/rev/7214e3324a45
>> ...
>> --- a/Misc/NEWS
>> +++ b/Misc/NEWS
>> ...
>> +- Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
>> + prevent readline() calls from consuming too much member.
>
>Maybe s/member/memory/ ?
Good catch, thanks.

Ping. Please fix before "beta 1".

Here's a max line lenght fix for 3.2 (applies on 3.4 too).
I wonder if _getlongresp should have some max length detection too for max length of a multiline response

New changeset 68029048c9c6 by Georg Brandl in branch '3.3':
Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
http://hg.python.org/cpython/rev/68029048c9c6 

Also merged to default.

New changeset 76be07730f8d by Georg Brandl in branch '3.2':
Issue #16041: CVE-2013-1752: poplib: Limit maximum line lengths to 2048 to
https://hg.python.org/cpython/rev/76be07730f8d 

Here is a patch for 2.7.

this looks ok to me, can we apply this for 2.7.9?

New changeset 339f877cca11 by Benjamin Peterson in branch '2.7':
in poplib, limit maximum line length that we read from the network (closes #16041)
https://hg.python.org/cpython/rev/339f877cca11 

This "fix" has broken mail retrieval from both gmx.de, gmail.com and plenty of other provider.
It manifests in getmail as:
Retrieval error: server for BrokenUIDLPOP3SSLRetriever:1860228@pop.gmx.net:995 is broken; offered message 239 but failed to provide it. Please notify the administrator of the server. Skipping message...
After setting the _MAXLINE in /usr/lib/python2.7/poplib.py to something higher everything was working again.
See issue #23906 

+1 to the above; suggest this should be rolled back and replaced with a total message size limit.

Broke for me today. Hacked the _MAXLINE to get around it.
I don't see any size limit on multi-line in rfc. Only requirement is dot-stuffing. I think this fix might need a rethink.

It has been, see the referenced issue. Now we just need someone to write a patch.