From 921bb6b2e3ac5e86397453e3bf5f43ac41c38980 Mon Sep 17 00:00:00 2001 From: Offensive Security Date: Tue, 12 Apr 2016 05:04:12 +0000 Subject: [PATCH] DB: 2016-04-12 9 new exploits Hikvision Digital Video Recorder - Cross-Site Request Forgery WPN-XM Serverstack 0.8.6 - Cross Site Request Forgery OpenCart 2.1.0.2 to 2.2.0.0 - json_decode Function Remote Code Execution CAM UnZip 5.1 - Archive Path Traversal Axis Network Cameras - Multiple Vulnerabilities Linux/x86_64 - bindshell (PORT: 5600) - 81 bytes Android - IOMX getConfig/getParameter Information Disclosure Android - IMemory Native Interface is Insecure for IPC Use Novell Service Desk 7.1.0_ 7.0.3 and 6.5 - Multiple Vulnerabilities --- files.csv | 9 ++ platforms/android/dos/39685.txt | 46 +++++++ platforms/android/dos/39686.txt | 90 +++++++++++++ platforms/hardware/webapps/39677.html | 53 ++++++++ platforms/hardware/webapps/39683.txt | 138 ++++++++++++++++++++ platforms/jsp/webapps/39687.txt | 172 +++++++++++++++++++++++++ platforms/lin_x86-64/shellcode/39684.c | 88 +++++++++++++ platforms/php/webapps/39678.txt | 113 ++++++++++++++++ platforms/php/webapps/39679.txt | 48 +++++++ platforms/windows/local/39680.txt | 103 +++++++++++++++ 10 files changed, 860 insertions(+) create mode 100755 platforms/android/dos/39685.txt create mode 100755 platforms/android/dos/39686.txt create mode 100755 platforms/hardware/webapps/39677.html create mode 100755 platforms/hardware/webapps/39683.txt create mode 100755 platforms/jsp/webapps/39687.txt create mode 100755 platforms/lin_x86-64/shellcode/39684.c create mode 100755 platforms/php/webapps/39678.txt create mode 100755 platforms/php/webapps/39679.txt create mode 100755 platforms/windows/local/39680.txt diff --git a/files.csv b/files.csv index a4b0b5c1c..daa431661 100755 --- a/files.csv +++ b/files.csv @@ -35898,3 +35898,12 @@ id,file,description,date,author,platform,type,port 39674,platforms/windows/local/39674.py,"Express Zip <= 2.40 - Path Traversal",2016-04-08,R-73eN,windows,local,0 39675,platforms/osx/local/39675.c,"Apple Intel HD 3000 Graphics driver 10.0.0 - Local Privilege Escalation",2016-04-08,"Piotr Bania",osx,local,0 39676,platforms/php/webapps/39676.txt,"op5 7.1.9 - Remote Command Execution",2016-04-08,hyp3rlinx,php,webapps,443 +39677,platforms/hardware/webapps/39677.html,"Hikvision Digital Video Recorder - Cross-Site Request Forgery",2016-04-11,LiquidWorm,hardware,webapps,80 +39678,platforms/php/webapps/39678.txt,"WPN-XM Serverstack 0.8.6 - Cross Site Request Forgery",2016-04-11,hyp3rlinx,php,webapps,80 +39679,platforms/php/webapps/39679.txt,"OpenCart 2.1.0.2 to 2.2.0.0 - json_decode Function Remote Code Execution",2016-04-11,"Naser Farhadi",php,webapps,80 +39680,platforms/windows/local/39680.txt,"CAM UnZip 5.1 - Archive Path Traversal",2016-04-11,hyp3rlinx,windows,local,0 +39683,platforms/hardware/webapps/39683.txt,"Axis Network Cameras - Multiple Vulnerabilities",2016-04-11,Orwelllabs,hardware,webapps,80 +39684,platforms/lin_x86-64/shellcode/39684.c,"Linux/x86_64 - bindshell (PORT: 5600) - 81 bytes",2016-04-11,"Ajith Kp",lin_x86-64,shellcode,0 +39685,platforms/android/dos/39685.txt,"Android - IOMX getConfig/getParameter Information Disclosure",2016-04-11,"Google Security Research",android,dos,0 +39686,platforms/android/dos/39686.txt,"Android - IMemory Native Interface is Insecure for IPC Use",2016-04-11,"Google Security Research",android,dos,0 +39687,platforms/jsp/webapps/39687.txt,"Novell Service Desk 7.1.0_ 7.0.3 and 6.5 - Multiple Vulnerabilities",2016-04-11,"Pedro Ribeiro",jsp,webapps,0 diff --git a/platforms/android/dos/39685.txt b/platforms/android/dos/39685.txt new file mode 100755 index 000000000..4b3d05bd3 --- /dev/null +++ b/platforms/android/dos/39685.txt @@ -0,0 +1,46 @@ +Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=711 + +Android: Information Disclosure in IOMX getConfig/getParameter +Platform: Verified on google/razor/flo:6.0.1/MMB29O/2459718:user/release-keys +Class: Information Disclosure + +Summary: +The GET_CONFIG and GET_PARAMETER calls on IOMX are vulnerable to an information disclosure of uninitialized heap memory. This could be used by an attacker to break ASLR in the media server process by reading out heap memory which contains useful address information. + +Description: +The relevant code in frameworks/av/media/libmedia/IOMX.cpp is: + +node_id node = (node_id)data.readInt32(); +OMX_INDEXTYPE index = static_cast(data.readInt32()); + +size_t size = data.readInt64(); + +void *params = malloc(size); +data.read(params, size); <- Read in the buffer from the parcel to initialize + + +// SNIP - getParameter etc. + +if ((code == GET_PARAMETER || code == GET_CONFIG) && err == OK) { + reply->write(params, size); <- Write back entire buffer to caller +} + +The vulnerability stems from the fact that Parcel::read(void* outData, size_t len) fails quickly if it doesn’t have sufficient data in the parcel to satisfy the request leaving the outData buffer untouched. As long as the call to getParameter or getConfig succeed then the entire, mostly uninitialized buffer will be returned. For example if the parameter is only 8 bytes in size but the caller passes a size field of 128 bytes (but doesn’t write those 128 bytes into the parcel) then the 120 bytes following in the heap will be returned uninitialized. + +Arguably there’s also a potential NULL pointer dereference here depending on the implementation as the call to malloc can fail with an arbitrary size value. But I think later functions handle the NULL case. +I’d suggest that the result of data.read should be checked to ensure all the data has been read correctly. + +Proof of Concept: +I’ve provided a PoC which exploits the issue and prints a 64 byte buffer (with 56 bytes uninitialized) to logcat. It uses the OMX.qcom.video.decoder.mpeg4 component. I’ve only tested this on a Nexus 5 and Nexus 7 devices, but I’m guessing that decoder should be everywhere. You should be able to create default Android Studio project and call OMXInfoDisclosurePoC.testOMX +from the Main Activity. When run you should see a line in logcat similar to: + +E/MyClass: allocateNode Error: 0 +E/MyClass: Allocate Node: 42 +E/MyClass: Result: 040000000101000XXXXXXXXXX + +Where XXXXXX should be uninitialized memory from the heap. + + +Proof of Concept: +https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39685.zip + diff --git a/platforms/android/dos/39686.txt b/platforms/android/dos/39686.txt new file mode 100755 index 000000000..05321e070 --- /dev/null +++ b/platforms/android/dos/39686.txt @@ -0,0 +1,90 @@ +Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=706 + +Android: IMemory Native Interface is insecure for IPC use +Platform: Tested on Android 6.0.1 January patches +Class: Elevation of Privilege + +Summary: +The IMemory interface in frameworks/native/libs/binder/IMemory.cpp, used primarily by the media services can be tricked to return arbitrary memory locations leading to information disclosure or memory corruption. + +Description: +The IMemory interface allows the passing of shared memory across the Binder IPC channel on Android. The interface supports a single remote call, GET_MEMORY which requests a separate IMemoryHeap interface along with an offset value and size for the shared memory buffer. The IMemoryHeap interface in turn supports a HEAP_ID call which marshals across a FileDescriptor, size, flags and an offset. This is passed to mmap to map the shared memory into the current process. + +The underlying vulnerability is the sizes in IMemory and IMemoryHeap are not checked relative to one another, and nor is the offset in IMemory checked against the size of IMemoryHeap. This allows a local process to craft fake IMemory and IMemoryHeap objects such that they lie about their values and either cause information disclosure or memory corruption. + +To understand this let’s look at how the pointer to the shared buffer is extracted from IMemory::pointer: + +void* IMemory::pointer() const { + ssize_t offset; + sp heap = getMemory(&offset); + void* const base = heap!=0 ? heap->base() : MAP_FAILED; + if (base == MAP_FAILED) + return 0; + return static_cast(base) + offset; <- No check on IMemoryHeap size +} + +Maybe we check sizes in getMemory() ? + +sp BpMemory::getMemory(ssize_t* offset, size_t* size) const +{ + if (mHeap == 0) { + Parcel data, reply; + data.writeInterfaceToken(IMemory::getInterfaceDescriptor()); + if (remote()->transact(GET_MEMORY, data, &reply) == NO_ERROR) { + sp heap = reply.readStrongBinder(); + ssize_t o = reply.readInt32(); + size_t s = reply.readInt32(); <- No check. + if (heap != 0) { + mHeap = interface_cast(heap); + if (mHeap != 0) { + mOffset = o; + mSize = s; + } + } + } + } + if (offset) *offset = mOffset; + if (size) *size = mSize; + return mHeap; +} + +Nope, as we can see, no check is made of IMemoryHeap’s size, so you could specify a mapped file smaller than offset and create a pointer out of bounds. Of course if IMemoryHeap is invalid then the mmap process will return MAP_FAILED which will end up as NULL after the call to pointer(). + +So how can this be abused? Any IPC service which calls pointer() can be tricked into accessing an arbitrary location, either a relative offset to the file mapped or NULL. For example look at ICrypto::onTransact with the DECRYPT operation. It checks that the offset is within the total size (this has been exploited before) with: + +} else if (totalSize > sharedBuffer->size()) { + result = -EINVAL; +} else if ((size_t)offset > sharedBuffer->size() - totalSize) { + result = -EINVAL; + +The size is the value returned through IMemory, and not the actual mapped size from IMemoryHeap so in this case offset can be arbitrary. With the right plugin (such as the clearkey plugin) we can get this to read arbitrary memory. Even more so as there’s no NULL checking in pointer() we can cause IMemoryHeap to fail which causes pointer() to return NULL. Setting size to 0xFFFFFFFF means we can read any memory location from 0 to 0xFFFFFFFF. + +This can be turned into an arbitrary write as long as you can pass an arbitrary IMemory to another service. For example the BnCameraRecordingProxy::onTransact in frameworks/av/camera/ICameraRecordingProxy.cpp does the following for onReleaseRecordingFrame + + +case RELEASE_RECORDING_FRAME: { + ALOGV("RELEASE_RECORDING_FRAME"); + CHECK_INTERFACE(ICameraRecordingProxy, data, reply); + sp mem = interface_cast(data.readStrongBinder()); + + if (CameraUtils::isNativeHandleMetadata(mem)) { + VideoNativeHandleMetadata *metadata = + (VideoNativeHandleMetadata*)(mem->pointer()); + metadata->pHandle = data.readNativeHandle(); + + // releaseRecordingFrame will be responsble to close the native handle. + } + releaseRecordingFrame(mem); + + return NO_ERROR; + } break; + +As you can coerce the pointer value, as long as the first 4 bytes make the integer 3 the next 4 bytes will be overwritten by the native handle value which can be controlled. + +Proof of Concept: +I’ve provided a PoC which exploits the issue in ICrypto::decrypt. I will just SIG_SEGV on reading an arbitrary location (in this case 1GiB relative to the mapped memory). If it succeeds then that’s good as well as it shouldn't succeed. You should be able to create default Android Studio project and replace the MainActivity with the provided Java file. When run it should cause media server to crash. + + +Proof of Concept: +https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39686.zip + diff --git a/platforms/hardware/webapps/39677.html b/platforms/hardware/webapps/39677.html new file mode 100755 index 000000000..2a7219e2e --- /dev/null +++ b/platforms/hardware/webapps/39677.html @@ -0,0 +1,53 @@ + + + + +
+ + +
+ + + diff --git a/platforms/hardware/webapps/39683.txt b/platforms/hardware/webapps/39683.txt new file mode 100755 index 000000000..4d27be4f8 --- /dev/null +++ b/platforms/hardware/webapps/39683.txt @@ -0,0 +1,138 @@ + _ _ _ _ + | | | | | | + ___ _ ____ _____| | | | __ _| |__ ___ + / _ \| '__\ \ /\ / / _ \ | | |/ _` | '_ \/ __| 6079 Smith W +| (_) | | \ V V / __/ | | | (_| | |_) \__ \ doubleplusungood + \___/|_| \_/\_/ \___|_|_|_|\__,_|_.__/|___/ owning some telescreens... + + + Security Adivisory + 2016-04-09 + www.orwelllabs.com + twt:@orwelllabs + + + + + +I. ADVISORY INFORMATION +----------------------- +Title: Axis Network Cameras Multiple Cross-site scripting +Vendor: Axis Communications +Class: Improper Input Validation [CWE-20] +CVE Name: CVE-2015-8256 +Remotely Exploitable: Yes +Locally Exploitable: No +OLSA-ID: OLSA-2015-8256 +Adivisory URL: +http://www.orwelllabs.com/2016/01/axis-network-cameras-multiple-cross.html + + +II. Background +-------------- +Axis is the market leader in network video, invented the world’s first +network camera back in 1996 and we’ve been innovators in video surveillance +ever since. Axis network video products are installed in public places and +areas such as retail chains, airports, trains, motorways, universities, +prisons, casinos and banks. + +III. vulnerability +------------------ +AXIS Network Cameras are prone to multiple (stored/reflected) cross-site +scripting vulnerability. + +IV. technical details +--------------------- +These attack vectors allow you to execute an arbitrary javascript code in +the user browser (session) with this steps: + +# 1 Attacker injects a javascript payload in the vulnerable page: +http://{axishost}/axis-cgi/vaconfig.cgi?action=get&name= + +* A reflected cross-site scripting affects all models of AXIS devices on +the same parameter: +http:// +{axis-cam-model}/view/view.shtml?imagePath=0WLL