in zipimport.c
1116 bytes_size = compress == 0 ? data_size : data_size + 1;
1117 if (bytes_size == 0)
1118 bytes_size++;
1119 raw_data = PyBytes_FromStringAndSize((char *)NULL, bytes_size);

If compress != 0, then bytes_size = data_size + 1
data_size is not sanitized, so if data_size = -1, then it overflows and becomes 0.
In that case bytes_size becomes 1 and python allocates small heap, but after that in fread, it overflows heap.

New changeset 01ddd608b85c by Benjamin Peterson in branch '3.4':
prevent buffer overflow in get_data (closes bpo-26171)
https://hg.python.org/cpython/rev/01ddd608b85c

New changeset 985fc64c60d6 by Benjamin Peterson in branch '2.7':
prevent buffer overflow in get_data (closes bpo-26171)
https://hg.python.org/cpython/rev/985fc64c60d6

New changeset 10dad6da1b28 by Benjamin Peterson in branch '3.5':
merge 3.4 (bpo-26171)
https://hg.python.org/cpython/rev/10dad6da1b28

New changeset 2df462852464 by Benjamin Peterson in branch 'default':
merge 3.5 (bpo-26171)
https://hg.python.org/cpython/rev/2df462852464

in zipimport.c
1116 bytes_size = compress == 0 ? data_size : data_size + 1;
1117 if (bytes_size == 0)
1118 bytes_size++;
1119 raw_data = PyBytes_FromStringAndSize((char *)NULL, bytes_size);

If compress != 0, then bytes_size = data_size + 1
data_size is not sanitized, so if data_size = -1, then it overflows and becomes 0.
In that case bytes_size becomes 1 and python allocates small heap, but after that in fread, it overflows heap.

I believe this should be applied to Python 3.3 as well, since the same problem (unchecked data_size before adding +1 for bytes_size) exists there too, and is thus a security issue.

reopening for 3.3.7 evaluation. Georg?

Here's the patch that I made for FreeBSD's Python 3.3 port. With this patch, on FreeBSD, Python 3.3 built fine and passed the zipimport related unit tests. It's basically the same code from 3.4, 3.5 and 2.7, just placed at appropriate place in the source.

Any updates on this? We've committed the patch for Python 3.3 as well in FreeBSD.

https://svnweb.freebsd.org/ports?view=revision&revision=417019

New changeset 5ae8756a1ae0 by Berker Peksag in branch '3.3':
Issue bpo-26171: Prevent buffer overflow in get_data
https://hg.python.org/cpython/rev/5ae8756a1ae0

New changeset fa006d671f41 by Berker Peksag in branch '3.4':
Issue bpo-26171: Null merge
https://hg.python.org/cpython/rev/fa006d671f41

New changeset 2fb148cd95a2 by Berker Peksag in branch '3.5':
Issue bpo-26171: Null merge
https://hg.python.org/cpython/rev/2fb148cd95a2

New changeset aa0c49b8edae by Berker Peksag in branch '3.6':
Issue bpo-26171: Null merge
https://hg.python.org/cpython/rev/aa0c49b8edae

New changeset f3df6b16af7d by Berker Peksag in branch 'default':
Issue bpo-26171: Null merge
https://hg.python.org/cpython/rev/f3df6b16af7d

Thanks!

I think patches put up in http://bugs.python.org/msg258736 is at least not sufficient enough for Python 2.7.
POC script(crash.py) provided with the issue calls get_data with data_size = -1.
I am using Python 2.7.8 . I patched the same with the solution provided in https://hg.python.org/cpython/rev/985fc64c60d6 . I was still able to reproduce the issue and it failed with

Traceback (most recent call last):
  File "crash.py", line 25, in <module>
    print(importer.get_data(FILE))
IOError: zipimport: can't read data
Segmentation fault (core dumped)

but I couldn't reproduce the same with latest 2.7.12:-

jchang@qasus-ubun12x64-001:~/Downloads/Python-2.7.12$ python2.7 -V
Python 2.7.12
jchang@qasus-ubun12x64-001:~/Downloads/Python-2.7.12$ python2.7 crash.py
Traceback (most recent call last):
  File "crash.py", line 25, in <module>
    print(importer.get_data(FILE))
zipimport.ZipImportError: negative data size

As we can see issue does happen in 2.7.12 because of following extra check :-

if (data_size < 0) {
        PyErr_Format(ZipImportError, "negative data size");
        return NULL;
    }

which was merged in https://hg.python.org/cpython/rev/2edbdb79cd6d.

I was thinking of backporting the same to Python 2.7.8 as well to completely address this issue. Could you guys confirm if my understanding is correct on this ? Thanks

Parvesh, we only maintain the latest micro release of a release cycle; for 2.7, that is currently 2.7.12. In other words, once 2.7.9 was released, 2.7.8 was no longer supported by us (although, of course, downstream distributors of Cpython can choose to backport fixes to older releases on their own).