
45 changes to exploits/shellcodes Cisco ASA - Crash PoC Cisco ASA - Crash (PoC) GNU binutils 2.26.1 - Integer Overflow (POC) GNU binutils 2.26.1 - Integer Overflow (PoC) K7 Total Security 15.1.0.305 - Device Driver Arbitrary Memory Read Linux Kernel - 'AF_PACKET' Use-After-Free Oracle Java JDK/JRE < 1.8.0.131 / Apache Xerces 2.11.0 - 'PDF/Docx' Server Side Denial of Service Microsoft Edge Chakra JIT - 'GlobOpt::OptTagChecks' Must Consider IsLoopPrePass Properly (2) Microsoft Edge Chakra JIT - Memory Corruption Microsoft Edge Chakra JIT - ImplicitCallFlags Checks Bypass Microsoft Edge Chakra JIT - Array Type Confusion via InitProto Instructions Microsoft Edge Chakra JIT - 'Array.prototype.reverse' Array Type Confusion Microsoft Edge Chakra JIT - 'NewScObjectNoCtor' Array Type Confusion Microsoft Edge Chakra JIT - 'LdThis' Type Confusion Pdfium - Pattern Shading Integer Overflows Pdfium - Out-of-Bounds Read with Shading Pattern Backed by Pattern Colorspace Chrome V8 - 'Runtime_RegExpReplace' Integer Overflow Hotspot Shield - Information Disclosure Linux Kernel (Ubuntu 17.04) - 'XFRM' Local Privilege Escalation Nitro Pro PDF - Multiple Vulnerabilities Odoo CRM 10.0 - Code Execution Dashlane - DLL Hijacking LightDM (Ubuntu 16.04/16.10) - Guest Account Local Privilege Escalation LightDM (Ubuntu 16.04/16.10) - 'Guest Account' Local Privilege Escalation Trustwave SWG 11.8.0.27 - SSH Unauthorized Access Ichano AtHome IP Cameras - Multiple Vulnerabilities Cisco UCS Platform Emulator 3.1(2ePE1) - Remote Code Execution Ikraus Anti Virus 2.16.7 - Remote Code Execution McAfee Security Scan Plus - Remote Command Execution OrientDB - Code Execution 360 Total Security - Local Privilege Escalation HPE Intelligent Management Center (iMC) 7.2 (E0403P10) - Code Execution Oracle Knowledge Management 12.1.1 < 12.2.5 - XML External Entity Leading To Remote Code Execution iBall WRA150N - Multiple Vulnerabilities GitStack - Unauthenticated Remote Code Execution Monstra CMS - Remote Code Execution Ametys CMS 4.0.2 - Unauthenticated Password Reset DblTek - Multiple Vulnerabilities FiberHome - Directory Traversal PHP Melody 2.7.3 - Multiple Vulnerabilities Tiandy IP Cameras 5.56.17.120 - Sensitive Information Disclosure Horde Groupware 5.2.21 - Unauthorized File Download QNAP HelpDesk < 1.1.12 - SQL Injection Hanbanggaoke IP Camera - Arbitrary Password Change McAfee LiveSafe 16.0.3 - Man In The Middle Registry Modification Leading to Remote Command Execution Sophos XG Firewall 16.05.4 MR-4 - Path Traversal Cisco DPC3928 Router - Arbitrary File Disclosure IDERA Uptime Monitor 7.8 - Multiple Vulnerabilities Geneko Routers - Unauthenticated Path Traversal Dasan Networks GPON ONT WiFi Router H640X versions 12.02-01121 / 2.77p1-1124 / 3.03p2-1146 - Unauthenticated Remote Code Execution
220 lines
No EOL
9 KiB
Text
220 lines
No EOL
9 KiB
Text
This vulnerability relies on several minor oversights in the handling of shading patterns in pdfium, I'll try to detail all of the issues that could be fixed to harden the code against similar issues.
|
|
|
|
The DrawXShading functions in cpdf_renderstatus.cpp rely on a helper function to compute the number of output components resulting from applying multiple shading functions. Note that all of these functions appear to be vulnerable; the rest of this report discusses the specifics of triggering a heap-overflow using DrawRadialShading.
|
|
|
|
uint32_t CountOutputs(
|
|
const std::vector<std::unique_ptr<CPDF_Function>>& funcs) {
|
|
uint32_t total = 0;
|
|
for (const auto& func : funcs) {
|
|
if (func)
|
|
total += func->CountOutputs(); // <-- Issue #1 : integer overflow here
|
|
}
|
|
return total;
|
|
}
|
|
|
|
The lack of integer overflow checking would not be an issue if the parser enforced the limitations applied by the pdf specification to the functions applied (namely that the /Function section in a radial shading pattern should be either a 1-n function or an array of n 1-1 functions), as these preconditions would preclude any overflow from occuring. However, we can see in the loading code for CPDF_ShadingPattern that there is no such validation.
|
|
|
|
bool CPDF_ShadingPattern::Load() {
|
|
if (m_ShadingType != kInvalidShading)
|
|
return true;
|
|
|
|
CPDF_Dictionary* pShadingDict =
|
|
m_pShadingObj ? m_pShadingObj->GetDict() : nullptr;
|
|
if (!pShadingDict)
|
|
return false;
|
|
|
|
m_pFunctions.clear();
|
|
CPDF_Object* pFunc = pShadingDict->GetDirectObjectFor("Function");
|
|
if (pFunc) {
|
|
|
|
// Issue #2: we never validate that the signatures of the parsed Function object
|
|
// match the expected signatures for the shading type that we're parsing.
|
|
|
|
if (CPDF_Array* pArray = pFunc->AsArray()) {
|
|
m_pFunctions.resize(std::min<size_t>(pArray->GetCount(), 4));
|
|
for (size_t i = 0; i < m_pFunctions.size(); ++i)
|
|
m_pFunctions[i] = CPDF_Function::Load(pArray->GetDirectObjectAt(i));
|
|
} else {
|
|
m_pFunctions.push_back(CPDF_Function::Load(pFunc));
|
|
}
|
|
}
|
|
CPDF_Object* pCSObj = pShadingDict->GetDirectObjectFor("ColorSpace");
|
|
if (!pCSObj)
|
|
return false;
|
|
|
|
CPDF_DocPageData* pDocPageData = document()->GetPageData();
|
|
m_pCS = pDocPageData->GetColorSpace(pCSObj, nullptr);
|
|
if (m_pCS)
|
|
m_pCountedCS = pDocPageData->FindColorSpacePtr(m_pCS->GetArray());
|
|
|
|
m_ShadingType = ToShadingType(pShadingDict->GetIntegerFor("ShadingType"));
|
|
|
|
// We expect to have a stream if our shading type is a mesh.
|
|
if (IsMeshShading() && !ToStream(m_pShadingObj.Get()))
|
|
return false;
|
|
|
|
return true;
|
|
}
|
|
|
|
Assuming that we can create function objects with very large output sizes, we can then reach the following code (in cpdf_renderstatus.cpp) when rendering something using the pattern:
|
|
|
|
void DrawRadialShading(const RetainPtr<CFX_DIBitmap>& pBitmap,
|
|
CFX_Matrix* pObject2Bitmap,
|
|
CPDF_Dictionary* pDict,
|
|
const std::vector<std::unique_ptr<CPDF_Function>>& funcs,
|
|
CPDF_ColorSpace* pCS,
|
|
int alpha) {
|
|
|
|
// ... snip ...
|
|
|
|
uint32_t total_results =
|
|
std::max(CountOutputs(funcs), pCS->CountComponents());
|
|
|
|
// NB: CountOutputs overflows here, result_array will be a stack buffer if we return
|
|
// a resulting size less than 16) or a heap buffer if the size is larger.
|
|
|
|
CFX_FixedBufGrow<float, 16> result_array(total_results);
|
|
float* pResults = result_array;
|
|
memset(pResults, 0, total_results * sizeof(float));
|
|
uint32_t rgb_array[SHADING_STEPS];
|
|
for (int i = 0; i < SHADING_STEPS; i++) {
|
|
float input = (t_max - t_min) * i / SHADING_STEPS + t_min;
|
|
int offset = 0;
|
|
for (const auto& func : funcs) {
|
|
if (func) {
|
|
int nresults;
|
|
|
|
// Here we've desynchronised the size of the memory pointed to by
|
|
// pResults with the actual output size of the functions, so this
|
|
// can write outside the allocated buffer.
|
|
|
|
if (func->Call(&input, 1, pResults + offset, &nresults))
|
|
offset += nresults;
|
|
}
|
|
}
|
|
float R = 0.0f;
|
|
float G = 0.0f;
|
|
float B = 0.0f;
|
|
pCS->GetRGB(pResults, &R, &G, &B);
|
|
rgb_array[i] =
|
|
FXARGB_TODIB(FXARGB_MAKE(alpha, FXSYS_round(R * 255),
|
|
FXSYS_round(G * 255), FXSYS_round(B * 255)));
|
|
}
|
|
|
|
Now we need to revisit our earlier assumption, that we can create function objects with large output sizes.
|
|
|
|
The following code handles parsing of function objects:
|
|
|
|
bool CPDF_Function::Init(CPDF_Object* pObj) {
|
|
CPDF_Stream* pStream = pObj->AsStream();
|
|
CPDF_Dictionary* pDict = pStream ? pStream->GetDict() : pObj->AsDictionary();
|
|
|
|
CPDF_Array* pDomains = pDict->GetArrayFor("Domain");
|
|
if (!pDomains)
|
|
return false;
|
|
|
|
m_nInputs = pDomains->GetCount() / 2;
|
|
if (m_nInputs == 0)
|
|
return false;
|
|
|
|
m_pDomains = FX_Alloc2D(float, m_nInputs, 2);
|
|
for (uint32_t i = 0; i < m_nInputs * 2; i++) {
|
|
m_pDomains[i] = pDomains->GetFloatAt(i);
|
|
}
|
|
CPDF_Array* pRanges = pDict->GetArrayFor("Range");
|
|
m_nOutputs = 0;
|
|
if (pRanges) {
|
|
m_nOutputs = pRanges->GetCount() / 2;
|
|
m_pRanges = FX_Alloc2D(float, m_nOutputs, 2); // <-- avoid this call
|
|
for (uint32_t i = 0; i < m_nOutputs * 2; i++)
|
|
m_pRanges[i] = pRanges->GetFloatAt(i);
|
|
}
|
|
uint32_t old_outputs = m_nOutputs;
|
|
if (!v_Init(pObj))
|
|
return false;
|
|
if (m_pRanges && m_nOutputs > old_outputs) {
|
|
m_pRanges = FX_Realloc(float, m_pRanges, m_nOutputs * 2); // <-- avoid this call
|
|
if (m_pRanges) {
|
|
memset(m_pRanges + (old_outputs * 2), 0,
|
|
sizeof(float) * (m_nOutputs - old_outputs) * 2);
|
|
}
|
|
}
|
|
return true;
|
|
}
|
|
|
|
We can only have 4 functions, so we need m_nOutputs to be pretty large. Ideally we also don't want our pdf file to contain arrays of size 0x100000000 // 4 either, since this will mean multiple-gigabyte pdfs. Note also that any call to the FX_ allocation functions will fail on very large values, so ideally we need to follow the case old_outputs == m_nOutputs == 0, avoiding the final FX_Realloc call and allowing an arbitrarily large m_nOutputs.
|
|
|
|
It turns out that there is a function subtype that allows this, the exponential interpolation function type implemented in cpdf_expintfunc.cpp
|
|
|
|
bool CPDF_ExpIntFunc::v_Init(CPDF_Object* pObj) {
|
|
CPDF_Dictionary* pDict = pObj->GetDict();
|
|
if (!pDict)
|
|
return false;
|
|
|
|
CPDF_Array* pArray0 = pDict->GetArrayFor("C0");
|
|
if (m_nOutputs == 0) {
|
|
m_nOutputs = 1;
|
|
if (pArray0) {
|
|
fprintf(stderr, "C0 %zu\n", pArray0->GetCount());
|
|
m_nOutputs = pArray0->GetCount();
|
|
}
|
|
}
|
|
|
|
CPDF_Array* pArray1 = pDict->GetArrayFor("C1");
|
|
m_pBeginValues = FX_Alloc2D(float, m_nOutputs, 2);
|
|
m_pEndValues = FX_Alloc2D(float, m_nOutputs, 2);
|
|
for (uint32_t i = 0; i < m_nOutputs; i++) {
|
|
m_pBeginValues[i] = pArray0 ? pArray0->GetFloatAt(i) : 0.0f;
|
|
m_pEndValues[i] = pArray1 ? pArray1->GetFloatAt(i) : 1.0f;
|
|
}
|
|
|
|
m_Exponent = pDict->GetFloatFor("N");
|
|
m_nOrigOutputs = m_nOutputs;
|
|
if (m_nOutputs && m_nInputs > INT_MAX / m_nOutputs) // <-- can't be *too* large
|
|
return false;
|
|
|
|
m_nOutputs *= m_nInputs; // <-- but it can be pretty large
|
|
|
|
// Issue #3: This is probably not the place, but it probably makes sense to
|
|
// bound m_nInputs and m_nOutputs to some large-but-not-that-large value in
|
|
// CPDF_Function::Init
|
|
|
|
return true;
|
|
}
|
|
|
|
So, by providing a function object without a /Range object, but with a large /C0 and /Domain elements, we can construct a function object with about INT_MAX outputs.
|
|
|
|
7 0 obj
|
|
<<
|
|
/FunctionType 2
|
|
/Domain [
|
|
0.0 1.0
|
|
... repeat many times ...
|
|
0.0 1.0
|
|
]
|
|
/C0 [
|
|
0.0
|
|
... repeat many times ...
|
|
0.0
|
|
]
|
|
/N 1
|
|
>>
|
|
endobj
|
|
|
|
At this point it looks like we have quite an annoying exploitation primitive; we can write a huge amount of data out of bounds, but that data will be calculated as an interpolation between it's input coordinates, and it will be a really, really big memory corruption.
|
|
|
|
It turns out that the point mentioned earlier at Issue #2 about validating the signatures of the functions is again relevant here, since if we look at the callsite in DrawRadialShading we can see that all of the functions are called with a single input parameter, and if we look at the start of CPDF_Function::Call
|
|
|
|
bool CPDF_Function::Call(float* inputs,
|
|
uint32_t ninputs,
|
|
float* results,
|
|
int* nresults) const {
|
|
if (m_nInputs != ninputs)
|
|
return false;
|
|
|
|
We can see that any attempt to call a function with the wrong number of input parameters will simply fail, letting us control precisely the size and contents of our overflow.
|
|
|
|
The attached poc will crash under ASAN with the following stack-trace, and without ASAN during the free of the corrupted heap block.
|
|
|
|
Proof of Concept:
|
|
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44082.zip |