New issue
Advanced search Search tips

Issue 918233 link

Starred by 3 users
Status: Assigned
Owner:
mek@chromium.org
Cc:
nedwill@google.com
jsb...@chromium.org
mmoroz@chromium.org
mek@chromium.org
pwnall@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

use of uninitialized value of cache->owning_group may lead to sanbox escape

Reported by scdengy...@gmail.com, Dec 29 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce the problem:
./appcache_fuzzer poc

What is the expected behavior?

What went wrong?
1. kRegister(host_id=1)
2. kRegister(host_id=2)
3. kSelectCache, host_id=1, from_id=0, http://localhost/1
4. kDoRequest, code=206, do_not_cache=false, cache_id=1
    inprogress_cache_ = new AppCache(storage_, storage_->NewCacheId());// allocate an AppCache, but owning_group never initialized
5. kSelectCache, host_id=2, from_id=1, http://localhost/5
    AppCacheHost::FinishCacheSelection( cache, nullptr )
      cache->owning_group() // owning_group referenced here, cause a reference of unitialized value

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../content/browser/appcache/appcache_host.cc:404:41 in
../../content/browser/appcache/appcache_group.h:71:15: runtime error: member call on null pointer of type 'const content::AppCacheGroup *'
    #0 0x55b66466d569 in manifest_url content/browser/appcache/appcache_group.h
    #1 0x55b66466d569 in content::AppCacheHost::FinishCacheSelection(content::AppCache*, content::AppCacheGroup*) content/browser/appcache/appcache_host.cc:404
    #2 0x55b66473fbf9 in content::AppCacheStorageImpl::LoadCache(long, content::AppCacheStorage::Delegate*) content/browser/appcache/appcache_storage_impl.cc:1472:15
    #3 0x55b66466aa31 in content::AppCacheHost::SelectCache(GURL const&, long, GURL const&) content/browser/appcache/appcache_host.cc:131:5
    #4 0x55b6645eb11c in content::AppCacheBackendImpl::SelectCache(int, GURL const&, long, GURL const&) content/browser/appcache/appcache_backend_impl.cc:64:16
    #5 0x55b664631afa in content::AppCacheDispatcherHost::SelectCache(int, GURL const&, long, GURL const&) content/browser/appcache/appcache_dispatcher_host.cc:85:24

Did this work before? N/A 

Chrome version: 71.0.3578.98  Channel: stable
OS Version: OS X 10.14.2
Flash Version:
crash.log
7.8 KB View Download

Comment 1 by mpdenton@google.com, Dec 30

Cc: jsb...@chromium.org nedwill@google.com
Components: Blink>Storage>AppCache
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Owner: pwnall@chromium.org
Status: Assigned (was: Unconfirmed)
Thanks for the report! This is not a use of an uninitialized value, as the value of cache->owning_group is indeed initialized to nullptr. Thus this is only a nullptr dereference, which is not considered a security issue.

When I run the poc, I get the CHECK failure from  issue 917827 , so this may be a duplicate.

Comment 2 by pwnall@chromium.org, Jan 11

Cc: pwnall@chromium.org
Owner: mek@chromium.org
mek@, could you please investigate?

Comment 3 by mek@chromium.org, Jan 15

Cc: mek@chromium.org mmoroz@chromium.org
 Issue 921907  has been merged into this issue.

Comment 4 by mek@chromium.org, Jan 15 

Part of the problem here is that AppCacheHost blindly trusts whatever the renderer reports as "cache_document_was_loaded_from" when calling SelectCache, even though the browser process of course already should know what cache the document was actually loaded from.

In this case the id that is passed does match a existing cache, but not one that is currently owned by any group, ergo not the cache that the document was actually loaded from. Probably the correct thing would be for AppCacheRequestHandler to store what cache it actually loaded a main resource from, and BadMessage if the renderer comes back with a completely different id. Not sure if there are edge cases I'm missing where those numbers could be different.
Project Member

Comment 5 by ClusterFuzz, Jan 15

Labels: OS-Chrome OS-Windows OS-Linux
Project Member

Comment 6 by ClusterFuzz, Jan 15 

ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5661201962631168.
Project Member

Comment 7 by ClusterFuzz, Jan 16

Labels: Security_Impact-Beta
Detailed report: https://clusterfuzz.com/testcase?key=5661201962631168

Fuzzer: libFuzzer_appcache_fuzzer
Fuzz target binary: appcache_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000028
Crash State:
  GURL::spec
  content::AppCacheHost::FinishCacheSelection
  content::AppCacheStorageImpl::LoadCache
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=605707:605713

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5661201962631168

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.
Project Member

Comment 8 by ClusterFuzz, Yesterday (37 hours ago)

Labels: M-73 Fuzz-Blocker ReleaseBlock-Beta
This crash occurs very frequently on windows platform and is likely preventing the fuzzer appcache_fuzzer from making much progress. Fixing this will allow more bugs to be found.

Marking this bug as a blocker for next Beta release.

If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.
►

Sign in to add a comment