New issue
Advanced search Search tips

Issue 757506 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment

UAF in in CPWL_ListCtrl::~CPWL_ListCtrl()

Reported by manhluat...@gmail.com, Aug 21 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Steps to reproduce the problem:
1. Get Chromium ASAN (e.g: asan-mac-debug-495837)
Chromium	62.0.3192.0 (Developer Build) (64-bit)
Revision	e0739daa74157a3ed9446dbafdc3a2d9ca81846b-refs/heads/master@{#495837}

2. Open |listbox.pdf|

3. ASAN crashes.

What is the expected behavior?

What went wrong?
Looks like UAF occurs in CPWL_ListCtrl object.

Document JS Action:

    this.getField("MyField").setFocus();
    app.setTimeOut('this.pageNum = 3;',5000);

Did this work before? N/A 

Chrome version: 60.0.3112.101  Channel: stable
OS Version: OS X 10.12.6
Flash Version:
 
listbox.in
1.6 KB Download
listbox.pdf
2.6 KB Download

Comment 1 by tsepez@chromium.org, Aug 21 2017

Labels: Security_Severity-Low Security_Impact-Stable
Owner: dsinclair@chromium.org
Thanks.  Crashes in ProbeForLowSeverityLifetimeIssue() are low-severity issues.
We fix them quickly, though, because they are indications that the programmer isn't following a strict lifetime discipline, and there may be other lurking issues.
Cc: dsinclair@chromium.org
Owner: hnakashima@chromium.org
hnakashima@ can you take a look at this one? Thanks.
cool, hopefully it will get fixed soon since i'm working on it. Thanks

Comment 4 by rsesek@chromium.org, Aug 21 2017

Components: Internals>Plugins>PDF

Comment 5 by rsesek@chromium.org, Aug 21 2017

Status: Assigned (was: Unconfirmed)
Status: Started (was: Assigned)
This looks fairly harmless.

- ~CFFL_ListBox() calls the parent destructor
- ~CFFL_TextObject() deletes m_pFontMap (member) and calls the parent destructor
- ~CFFL_FormFiller() calls CFFL_FormFiller::DestroyWindows()
- CFFL_FormFiller::DestroyWindows() deletes the CPWL_ListBox
- ~CPWL_ListBox() deletes m_pList (member) calling its destructor
- ~CPWL_ListCtrl() sees a dangling reference to a font map that used to be a member of CFFL_TextObject and crashes.


Yes it seems
Project Member

Comment 9 by bugdroid1@chromium.org, Aug 23 2017

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/0924119cae45955525b25c915b3eda90d3e3bd20

commit 0924119cae45955525b25c915b3eda90d3e3bd20
Author: Henrique Nakashima <hnakashima@chromium.org>
Date: Wed Aug 23 20:49:50 2017

Fixed ASan crash when unloading page with CFFL_ListBox.

The crash was caused by a dangling pointer in CPWL_ListCtrl to
the font map owned by CFF_TextObject. The order of events was:
1. ~CFFL_ListBox runs and calls parent destructor ~CFFL_TextObject.
2. ~CFFL_TextObject runs and deletes its member m_pFontMap. m_FontMap
  was referenced by CPWL_ListCtrl which is now dangling.
3. ~CFFL_TextObject calls parent destructor ~CFFL_FormFiller.
4. ~CFFL_FormFiller calls DestroyWindows().
5. CFFL_FormFiller::DestroyWindows() deletes widgets, among them
  CPWL_ListBox.
6. ~CPWL_ListBox deletes its member CPWL_ListCtrl.
7. ~CPWL_ListCtrl sees a dangling pointer to the map and crashes.

Making the DestroyWindows() call earlier in the destructor of
CFFL_TextObject, we execute steps 5-7 before freeing m_pFontMap.

An extra DestroyWindows() is still made in ~CFFL_FormFiller, but
it is then non-op if the derived CFFL_TextObject already called it.

Bug:  chromium:757506 
Change-Id: Ib8dce04f1dd0bcf8e10701f6cf7ea500bfb5ba84
Reviewed-on: https://pdfium-review.googlesource.com/11651
Commit-Queue: Henrique Nakashima <hnakashima@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>

[modify] https://crrev.com/0924119cae45955525b25c915b3eda90d3e3bd20/fpdfsdk/formfiller/cffl_textobject.cpp

Status: Fixed (was: Started)
Project Member

Comment 11 by sheriffbot@chromium.org, Aug 24 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel OS-iOS
Hi manhluat93.php@ - the VRP panel looked at this, and would be interested in seeing what happens if you try to reproduce after removing the ProbeForLowSeverityLifetimeIssue() check, as it might be masking a higher severity issue.

Comment 14 Deleted

Hi,
It depends on behavior of CFX_UnownedPtr, but in this case I would say it's not harmful and exploitable. so you can leave it as low one :)
Labels: -reward-topanel reward-0
Thanks manhluat93.php@ - after some investigation our end we concur that it's a low severity issue.  Cheers.
Project Member

Comment 17 by sheriffbot@chromium.org, Nov 30 2017

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment