[Question] General interest in additional crashes from fuzzing `Typescript`

[0xricksanchez]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

Hi Typescript team,

As mentioned in the last issue I created, we added multiple harnesses for TypeScript into Google's OSS-Fuzz project recently with our JS/TS fuzzer Jazzer.js.

From a quick glance at the recent crashes, it looks like there might be several more crashes related to what seems to be scattered (debug) assertions in the code as before (e.g.: Error: Debug Failure. Expected 21 <= 20)

Additionally, there seem to be a couple of crashes that were caused by: RangeError: Maximum call stack size exceeded.

I reported the latter crash type with an example write-up to MSRC as stated by the security policy in place in this repo, but it was closed due to: [...] isnt a security invariant. [...].
While I partially agree, I still feel that this, as is, could at least be considered a "local DoS" of e.g. the TypeScript compiler. The impact of this is discussable.

So bottom-line, before dismissing all of these findings, I wanted to reach out here.
These crash types seem to occur quite frequently in the harnesses we built, and before we invest significant effort into root causing these and potentially filing issues, I wanted to ask if this would be something you'd be interested in the first place.

Cheers

[RyanCavanaugh]

In general, crashes in debug asserts are pretty interesting since they represent invariants that might get violated in other ways. Same for any other "cannot read property X of undefined" or such crash; those are something we'd like to hear about.

Crashes in stack overflows due to writing extremely-nested productions aren't something we think needs "fixing"; TS is here to process actual code and we're willing to crash/OOM on degenerate inputs for the sake of making mainline scenarios more performant.

a "local DoS"

"tsc will not crash on any input, ever" isn't a security boundary; if you have a process that depends on tsc never crashing, please reassess your usage of it. Attacker-controlled behavior would be a security problem, but irregular exit isn't.

[0xricksanchez]

In general, crashes in debug asserts are pretty interesting since they represent invariants that might get violated in other ways. Same for any other "cannot read property X of undefined" or such crash; those are something we'd like to hear about.

Perfect. I'll get a grasp about how many unique crashes we have collected on that front. How would you like to receive these? Via MSRC or just plain public bug reports here @RyanCavanaugh?
Initial assessment from our end will obviously consider possibilities how the set constraints could be violated but if you'd prefer all such occurrences to be communicated privately that's fine by us as well

"tsc will not crash on any input, ever" isn't a security boundary; if you have a process that depends on tsc never crashing, please reassess your usage of it. Attacker-controlled behavior would be a security problem, but irregular exit isn't.

I think that's fair and aligns with my view as well. We're not pursuing/filing those kinds of crashes then.

[RyanCavanaugh]

Just bug reports please; there's huge overhead via MSRC 😅

[0xricksanchez]

Okay cool, I consider this "issue" done then, and we're going to triage what we have so far and file issues when relevant :)