Important Note 1 is totally expected since the same process is used to render more than one PDF file.

Important Note 2 seems to indicate that there is some difference in the flags being supplied to chrome.  You might want to double-check the shortcut to see what is actually being executed on your system.

Keeping security-restrictions for now but this may just be a null-deref functional crash rather than a security issue per-se.

Linux/ASAN/pdfium_test didn't kick out any issue.  This may require a gesture to reproduce.

Hello tsepez@chromium.org,

Good Evening.

No flag/switch is being supplied to chrome. The shortcut Target is basic chrome path. => "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

And yes, Linux/ASAN/pdfium_test does not reproduce, as mentioned above "OS=Windows; Version= 57.0.2987.110 + Stable" and no CLI usage.

Also not sure how gestures could cause the crash, since the crash occurs after the PDF is loaded and few seconds have passed. No user supplied action/gesture like click,zoom,etc is required to reproduce this vulnerability.

Thanks,
Kushal.

I can't repro this on 57.0.2987.110 macOS and don't have a Windows machine to test on.

Can you attach a crash report "Server ID" from chrome://crashes?

File works for me on Windows 59.0.3047.0 (Official Build) canary (64-bit). It also works for me on Windows 57.0.2987.110 (Official Build) (64-bit)

Hello rsesek@chromium.org,

I enabled the automatic crash reporting feature under Privacy on 2 separate physical machines where the vulnerability is triggered on the latest Chrome 57.0.2987.110 Stable version.

The crash ID details are as follows: -

Machine1: Crash ID 169e5d86-f06c-4abe-b87e-74da3b365b3f (Server ID: a371265480000000)

Machine2: Crash ID aa16ba72-2683-4664-ab91-f1091236d79c (Server ID: 9e95d2e160000000)

Thanks,
Kushal.

Looks like out of memory. Do you have ome accessibility feature enabled?

Hello thestig@chromium.org,

I do not have any accessibility feature enabled on either of the Chrome Browser installations on both machines.

Thanks,
Kushal.

Well, it's crashing in accesibility code anyhow. I think this may be a duplicate of bug 648981. Does it still happen with Chrome Canary?

dmazzoni: We merged r447344 to M57, but not r447132?

Hello thestig@chromium.org,

Good Afternoon.

I am not sure how the accessibility code is encountered. Also I do not have access to bug 648981 and thus cannot confirm how and if it is a duplicate of this one.

The vulnerability does not exist in Chrome Canary. Only the Chrome Windows Stable version is affected.

Thanks,
Kushal.

I'm not sure either. It's accessibility code somehow running on your computer. :)

Bug 648981 is restricted, but based on your feedback, this sounds like the same issue.

Hello thestig@chromium.org,

Good Afternoon.

"Accessibility code is somehow running on your computer" but I do not know about it...mysterious indeed..:) 

The second machine is a fresh imaged machine and has fresh default Chrome installation and thus has no extra chrome additions such as accessibility features.

Could you share how you are inferring that accessibility code is the cause?
Also could you share which accessibility feature/code you think is causing this bug?

Also "based on your feedback, this sounds like the same issue"? Not sure which feedback of mine, suggests Accessibility being the cause or Similarity to bug 648981? 

I understand that Bug 648981 is restricted, but it might help in the resolution, if access is granted for transparency purposes, if and only if this vulnerability is indeed a duplicate of bug 648981.

In the case that this vulnerability is not the same as bug 648981, then we need to triage it separately.

Eagerly awaiting your response in earnest.

Thanks & Regards,
- Kushal.

I'm looking at the stack trace, and it's crashing in the PDF plugin's accessibility code.

You said the bug doesn't exist on Canary, but exists on stable. That along with comment 9 make it sound like the same issue. Even if you can't see bug 648981, r447132 is public and you can work out what happened.

dmazzoni: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

dmazzoni: Uh oh! This issue still open and hasn't been updated in the last 29 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Does this issue exist in M59? Otherwise, let's close as per #13?

I don't believe this issue exists on Chrome 59. It only affects Chrome 57 because we didn't do a merge. However, Chrome 58 is going to stable so there is not much more we can do here.

If the above is wrong and this affects Chrome 58+, please say so and we can re-examine this bug report.

Hello Google Chrome Security Team, 

The issue was valid in Chrome Windows Stable version 57.0.2987.110.

I was unable to see any similarity to https://crrev.com/447132 or any connection to "apparently duplicate of and still non-transparently hidden crbug.com/648981 bug report".

The vulnerability existed in Stable 57.0.2987.110 and was reproducible too!!

Now, after a month and several code changes in Chrome since original report, this issue gets marked "WontFix". 

Didn't expect this kind of a response from Chrome Security Team.

~ Kushal.

So bug 648981 is a just a crash bug with potential PII that got marked as restricted. It's not a security bug. The fix for the bug is r447132. If you read the description of r447132, it tells you exactly what happened - the code treated -1 as a size_t, and then tried to allocate a ton of memory. When memory allocation fails, Chrome crashes.

You gave us 2 crash report IDs:

a371265480000000

	0x76d6c54f	(KERNELBASE.dll + 0x0000c54f )	RaiseException
	0x0f8d9ba6	(chrome_child.dll -throw.cpp:131 )	_CxxThrowException
	0x0f8d38e4	(chrome_child.dll -xthrow.cpp:20 )	std::_Xlength_error(char const *)
	0x103c68ec	(chrome_child.dll -vector:1569 )	std::vector<std::pair<ui::AXIntListAttribute,std::vector<int,std::allocator<int> > >,std::allocator<std::pair<ui::AXIntListAttribute,std::vector<int,std::allocator<int> > > > >::_Buy(unsigned int)
	0x1003868a	(chrome_child.dll -vector:718 )	std::vector<PP_PrivateAccessibilityCharInfo,std::allocator<PP_PrivateAccessibilityCharInfo> >::vector<PP_PrivateAccessibilityCharInfo,std::allocator<PP_PrivateAccessibilityCharInfo> >(unsigned int)
	0x1003d810	(chrome_child.dll -out_of_process_instance.cc:755 )	chrome_pdf::OutOfProcessInstance::SendNextAccessibilityPage(int)

9e95d2e160000000

	0x000007fefd7ca06d	(KERNELBASE.dll + 0x0001a06d )	RaiseException
	0x000007fee0d9de44	(chrome_child.dll -memory_win.cc:38 )	base::`anonymous namespace'::OnNoMemory
	0x000007fee05f6707	(chrome_child.dll -allocator_shim_override_ucrt_symbols_win.h:51 )	malloc
	0x000007fee0433564	(chrome_child.dll -new_scalar.cpp:19 )	operator new(unsigned __int64)
	0x000007fedfcb5c30	(chrome_child.dll -xmemory0:69 )	std::_Allocate(unsigned __int64,unsigned __int64,bool)
	0x000007fee137b839	(chrome_child.dll -vector:1572 )	std::vector<blink::WebFloatRect,std::allocator<blink::WebFloatRect> >::_Buy(unsigned __int64)
	0x000007fee0d80092	(chrome_child.dll -vector:718 )	std::vector<PP_PrivateAccessibilityCharInfo,std::allocator<PP_PrivateAccessibilityCharInfo> >::vector<PP_PrivateAccessibilityCharInfo,std::allocator<PP_PrivateAccessibilityCharInfo> >(unsigned __int64)
	0x000007fee0d85eaf	(chrome_child.dll -out_of_process_instance.cc:755 )	chrome_pdf::OutOfProcessInstance::SendNextAccessibilityPage(int)

So it's the exact same problem as bug 648981. Would you have preferred if we marked this as a duplicate instead?

With Chrome's release cycle, Chrome 58 is about to go to stable. That means we are not doing any more Chrome 57 releases. Therefore there is nothing more to do here. Like I said, if this affects Chrome 58, then we can reopen and do something about that, but we are not fixing Chrome 57 anymore.

BTW, I'm not actually on the Chrome Security Team, so please don't blame them for anything here.

Hello @thestig, Google Chrome Security Team,

Marked as duplicate and thereafter reporter being included into bug 648981 for transparency would have been ideal, if and only if one was sure of this issue being duplicate. 

Also the issue being a duplicate was never confirmed in the first place. 
Refer below: -
c#9 "think this may be a duplicate of bug 648981"
&
c#13 "make it sound like the same issue"

Synopsis: - 

1) Issue was reported in a Stable Chrome version 57.0.2987.110.
2) Issue was set aside and forgotten under the assumption of being a duplicate of bug 648981.
3) Time flies by and after few weeks issue gets marked as "WontFix" due to newer Stable version not getting affected.
4) Stable "non-asan" Chrome version 57.0.2987.110 build is not available to test, post update.

I would like to make it clear that no one is blaming anyone here. 

All I am saying here is that the approach undertaken in handling this issue "at the ripe time(before updates)" was not healthy and that the researcher is helpless after Stable version updates of Chrome. That's all.

Thanks,
~ Kushal.

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