##########################################################################
#### Felipe Andres Manzano * fmanzano@fceia.unr.edu.ar ####
#### updates in http://felipe.andres.manzano.googlepages.com/home ####
##########################################################################
'''
Sumary:
=======
The libpoppler pdf rendering library, can free uninitialized pointers,
leading to arbitrary code execution. This vulnerability results from
memory management bugs in the Page class constructor/destructor.
Technical Description - Exploit/Concept Code:
=============================================
Tests were performed using libpoppler util pdftotext taken from
git://git.freedesktop.org/git/poppler/poppler.
Other version where tried succesfully (the ones shiped with
debian/gentoo).
In the initialization of a Page object and under certain conditions a
member object skips initialization, but then is eventualy deleted. This
can be conducted to the situation in which an arbitrary pointer is
passed to the libc free and so the it gets apropiate for the malloc
maleficarum to enter the scene.
Look at the Page class constructor on Page.cc:231. First at the begining
of the function the member object pageWidgets isnt initialized then it
tries to check if the type of the annotations proposed on the pdf file
ar correct; if not it bails out to the label err2. Note that is some
incorcondance on the type of the anotation arise the member variable
pageWidgets is never initialized!
Page::Page(XRef *xrefA, int numA, Dict *pageDict, PageAttrs *attrsA, Form *form) {
Object tmp;
[...]
// annotations
pageDict->lookupNF("Annots", &annots);
if (!(annots.isRef() || annots.isArray() || annots.isNull())) {
error(-1, "Page annotations object (page %d) is wrong type (%s)",
num, annots.getTypeName());
annots.free();
goto err2;
}
// forms
pageWidgets = new FormPageWidgets(xrefA, this->getAnnots(&tmp),num,form);
tmp.free();
[...]
err2:
annots.initNull();
err1:
contents.initNull();
ok = gFalse;
}
But in the Page class destructor, Page.cc:309, pageWidgets is deleted
without any consideration. The Page destructor is inmediatelly called
after the erroneous Page construction.
Page::~Page() {
delete pageWidgets;
delete attrs;
annots.free();
contents.free();
}
It is worth mentioning that the pdf rendering scenario is friendly with
the heap massage technics because you will find lots of ways to allocate
or allocate/free memory in the already probided functionality. In the
POC I have used repetidely the 'name' of the fields of a pdf dictionary
to allocate memory. Each name allocates up to 127bytes and apparently
there is no limit in the number of fields.
The following excerpt is a sample verification of the existence of
Other pages: : 1 * 2 * 3 * 4 * 5 * 6 * 7 * 8 * 9 * 10 * 11 * Next>>
|
You are here: hacking technology
> Exploit
> Content
Category: Home
> Exploit