Prevent stack overflows by limiting recursion

[46bit]

Addresses #305

Until now it has been possible to trigger a stack overflow by passing crafted inputs (e.g. a string of 1000 (). This is problematic when using the library to parse user input.

This commit adds a recursion limit so long as the library is compiled with std. The limit ensures that malicious inputs cannot trigger a stack overflow, by preventing excessively deep recursion.

Since the SQL parser is so big, I've added this protection to every Parser method that returns a Result. The actual recursive patterns in the AST are more limited, but with such a large parser it's much harder to identify them and put targeted protections in place.

[alamb]

Thank you @46bit -- This is quite cool and close I think.

Given how low level the sqlparser crate is, I would like to minimize the dependencies as much as possible. https://crates.io/crates/scopeguard has a bunch of unsafe as well .

The use of Rc and unsafe to check a value that requires annotation everywhere somewhat overly complex to me

I was wondering how hard it would be to make a macro that avoids the need for scope_guard entirely. For example Instead of:

pubfn parse_msck(&mutself) -> Result<Statement,ParserError>{check_recursion_depth!(self);

I wonder if it would be possible to create, via macro functions like

pubfnparse_msck(&mutself) -> Result<Statement,ParserError>{self.remaining_depth -= 1;ifself.remaining_depth == 0{returnErr(ParserError::RecursionLimitExceeded);}let res = parse_msck_impl(self)?
self.remaining_depth += 1;}pubfnparse_msck_impl(&mutself) -> Result<Statement,ParserError>{// existing code here}

We could make it even more encapsulated perhaps via a RAA struct like:

structStackChecker<'a>{parser:&'amutParser,}implStackChecker{pubfntry_new(&mutparser) -> Result<Self>{// stack check here, and decrement depth}}implDropforStackChecker{fndrop(&mutself){self.parser.remaining_depth -= 1}}

If we truly need scopeguard, I think in this case we should contemplate incorporating the code by value (aka copy it in)

[46bit]

@alamb Thank you for the detailed review, I agree with pretty much all your points :) The overflow protection seems effective (we've been fuzzing it for a solid week now and haven't found a workaround) yet I definitely agree on finding a nicer implementation. I'll revisit this PR in the next few weeks as soon as time allows and work on getting it into a better place.

[alamb]

@alamb Thank you for the detailed review, I agree with pretty much all your points :) The overflow protection seems effective (we've been fuzzing it for a solid week now and haven't found a workaround) yet I definitely agree on finding a nicer implementation. I'll revisit this PR in the next few weeks as soon as time allows and work on getting it into a better place.

Awesome -- I can't wait to see it. Thank you for your contribution and sticking with it.

[coveralls]

Pull Request Test Coverage Report for Build 2352192388

• 130 of 132(98.48%) changed or added relevant lines in 2 files are covered.
• 72 unchanged lines in 5 files lost coverage.
• Overall coverage decreased (-0.6%) to 89.879%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser.rs	125	127	98.43%

Files with Coverage Reduction	New Missed Lines	%
src/parser.rs	1	83.69%
tests/sqlparser_redshift.rs	1	98.11%
tests/sqlparser_snowflake.rs	2	96.43%
tests/sqlparser_postgres.rs	16	97.76%
tests/sqlparser_common.rs	52	97.04%

Totals
Change from base Build 2328175823:	-0.6%
Covered Lines:	8365
Relevant Lines:	9307

---

💛 - Coveralls

[alamb]

Closing as stale -- please reopen if you still plan to work on it

[alamb]

I have an proposal, based partly on this PR, here: #764