wow!

WRITE of size 243 at 0x7f85eb7d0a70 thread T0
SCARINESS: 60 (multi-byte-write-stack-buffer-overflow)

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

It's not really a regression. This exists since the beginning of time :)

And yes, the fuzzer shows that hunspell is extremely vulnerable to broken dictionaries. 

But 
a) We knew that. That's why it's segregated into the render process.
b) I've got a fairly difficult time imagining an attack scenario - you'll need to modify a local file, intercept a download from a google site via https, or have broken free of the sandbox to modify the download code in browser. All of these imply that you probably don't need a crash exploit any more.

Given this information, can we reclassify this? If it's really a releaseblock, we will, in all likelihood, need to turn hunspell off. Hardening hunspell against broken dictionaries is a non-trivial task. 

Given that an incorrect dictionary has been used + that dictionary is not controlled by an attacker, I think we may low down the priority here. But might be good to get it fixed sometime later when we've got a chance.

I'm setting P-3 and removing M-label.

Btw, I have a CL to use .bdic as a dictionary (https://codereview.chromium.org/2089623002/).

This issue is a security regression. If you are not able to fix this quickly, please revert the change that introduced it.

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

I'm not sure that I know how to say to the Sheriffbot that we don't want this to be a blocker. CC'ing marbella@ for this. Also would like to know his opinion about the issue. 

In this case it's because the impact wasn't updated to stable after c#5. You can also set ReleaseBlock-NA as a last resort, but usually it means something else went wrong with the triage of the bug.

Based on the other comments and fact that this is Pri-3, I'm not sure we should even be tracking this as a security bug. I'll leave that up to someone else to decide.

ClusterFuzz has detected this issue as fixed in range 401846:401864.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4516632898830336

Fuzzer: libfuzzer_hunspell_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Stack-buffer-overflow WRITE {*}
Crash Address: 0x7f85eb7d0a70
Crash State:
  Hunspell::suggest
  LLVMFuzzerTestOneInput
  fuzzer::Fuzzer::ExecuteCallback
  
Recommended Security Severity: High

Regressed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=401002:401127
Fixed: https://cluster-fuzz.appspot.com/revisions?job=libfuzzer_chrome_asan&range=401846:401864

Minimized Testcase (0.58 Kb): https://cluster-fuzz.appspot.com/download/AMIfv964tNTjFpofUJAREsJgoEl3HlwGi9t0NuHpYKBO3AOEP_6BQ2571H61E3x5b9mghHSMfeH6E94up-EGWPjlGWBqBL070qL5B5j3yhzwwVXwlO1qyssFCvyK4T1zVb-ylq3F5aBUiWyFrGnHSNSOmQvvMYfvIQ?testcase_id=4516632898830336

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Request-XX label, where XX is the Chrome milestone.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on omahaproxy.appspot.com.

Your fix is very close to the branch point. After the branch happens, please make sure to check if your fix is in.

- Your friendly ClusterFuzz

CF marked this as Fixed because it cannot be reproduced with a new version of the fuzzer, now it uses .bdic contents as a dictionary.

Please mark security bugs as fixed as soon as the fix lands, and before requesting merges.

- Your friendly ClusterFuzz

groby: 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

aarya@: I'm not sure this is ClusterFuzz-Wrong. The original fuzzing step had a bug, which mmoroz@ fixed.

Also, not sure why this is re-assigned to me - there's nothing to be done, as far as I can tell. There is no fix to be merged. 

groby@, it has been assigned to you as per c#7.

Technically ClusterFuzz is correct here, but I assume we want to keep this open and hope to fix one day.

We can keep it open as a someday maybe, but I don't see this happening. The cost is extremely high, and the vulnerability is extremely low. 

Cost: The fix would be rewriting major parts of hunspell. The assumption that the dictionary is "correct" permeates pretty much the entire code base.

Vulnerability: 
* Dictionaries are downloaded in the browser process from a fixed google.com address via https
* This particular bug is in the suggest path, which is only activated on user gesture.

I'd argue that if you achieve any of the preconditions necessary to trigger this, you already have a viable exploit, without needing hunspell. (This is part of the reason why we isolated hunspell in the render process, IIRC - it's a large legacy code base with many issues).


If you'd still like to reopen, feel free to do so, but please mark it as available instead - unless my security assessment is wrong and there is a viable exploit path.

Re-opening per #22 and #23

WontFixing as per #23.

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

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.