Exploit the possiblities

Python 3.4 / 3.5 xmlparse_setattro() Type Confusion

Python 3.4 / 3.5 xmlparse_setattro() Type Confusion
Posted Oct 31, 2015
Authored by John Leitch

Python versions 3.4 and 3.5 suffer from a vulnerability caused by the behavior of the xmlparse_setattro() function. When called, the function uses the provided name argument in several conditional statements which assume that the name argument is a string. However, if a name argument is provided that is not a string, this logic will make several calls to PyUnicode_CompareWithASCIIString that expect a string, yet receive some other type of object, leading to a type confusion vulnerability.

tags | exploit, python
MD5 | 70d4f19e98a6ca159c903fd1b9a473ed

Python 3.4 / 3.5 xmlparse_setattro() Type Confusion

Change Mirror Download
Title: Python 3.4 and 3.5 xmlparse_setattro() Type Confusion
Credit: John Leitch (john@autosectools.com), Bryce Darling (darlingbryce@gmail.com)
Url1: http://autosectools.com/Page/Python-xmlparse_setattro-Type-Confusion
Url2: http://bugs.python.org/issue25019
Resolution: Fixed

Python 3.4 and 3.5 suffer from a vulnerability caused by the behavior of the xmlparse_setattro() function. When called, the function uses the provided name argument in several conditional statements which assume that the name argument is a string.

However, if a name argument is provided that is not a string, this logic will make several calls to PyUnicode_CompareWithASCIIString that expect a string, yet receive some other type of object, leading to a type confusion vulnerability:

static int
xmlparse_setattro(xmlparseobject *self, PyObject *name, PyObject *v)
{
/* Set attribute 'name' to value 'v'. v==NULL means delete */
if (v == NULL) {
PyErr_SetString(PyExc_RuntimeError, "Cannot delete attribute");
return -1;
}
assert(PyUnicode_Check(name));
if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) {
[...]
}

In some applications, it may be possible to exploit this behavior to achieve arbitrary code execution. The type confusion can be observed by running the following script:

from xml.parsers.expat import *
p = ParserCreate()
p.__setattr__(range(0xF), 0)

Which, depending on the arrangement of memory, may produce an exception such as this:

0:000> g
(d84.ce0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0086f904 ebx=0086f8fc ecx=0050005c edx=00b60138 esi=0050005e edi=00b60138
eip=61e9a967 esp=0086f8c8 ebp=0086f8e0 iopl=0 nv up ei ng nz na pe cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010287
python35!find_maxchar_surrogates+0x37:
61e9a967 0fb701 movzx eax,word ptr [ecx] ds:002b:0050005c=????
0:000> k3
ChildEBP RetAddr
0086f8e0 61e9aa35 python35!find_maxchar_surrogates+0x37 [c:\build\cpython\objects\unicodeobject.c @ 1417]
0086f908 61eabcf3 python35!_PyUnicode_Ready+0x35 [c:\build\cpython\objects\unicodeobject.c @ 1466]
0086f918 61c547c3 python35!PyUnicode_CompareWithASCIIString+0x13
[c:\build\cpython\objects\unicodeobject.c @ 10784]

To fix this issue, it is recommended that xmlparse_setattro() be updated to validate that the name argument is a string and return out of the function early if it is not. A proposed patch is attached.

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

November 2017

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    22 Files
  • 2
    Nov 2nd
    28 Files
  • 3
    Nov 3rd
    10 Files
  • 4
    Nov 4th
    1 Files
  • 5
    Nov 5th
    5 Files
  • 6
    Nov 6th
    15 Files
  • 7
    Nov 7th
    15 Files
  • 8
    Nov 8th
    13 Files
  • 9
    Nov 9th
    9 Files
  • 10
    Nov 10th
    9 Files
  • 11
    Nov 11th
    3 Files
  • 12
    Nov 12th
    2 Files
  • 13
    Nov 13th
    15 Files
  • 14
    Nov 14th
    17 Files
  • 15
    Nov 15th
    19 Files
  • 16
    Nov 16th
    15 Files
  • 17
    Nov 17th
    19 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close