[#103680] [Ruby master Bug#17843] Ruby on Rails error[BUG] Segmentation fault at 0x0000000000000110 ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin15] (#42110) — nayaronfire@...

Issue #17843 has been reported by nayaronfire (kk nayar).

7 messages 2021/05/01

[#103686] [Ruby master Misc#17845] Windows Ruby - ucrt build? — Greg.mpls@...

Issue #17845 has been reported by MSP-Greg (Greg L).

22 messages 2021/05/01

[#103690] [Ruby master Bug#17846] Percent mode changes the output from ERB beyond what is documented — wolf@...

Issue #17846 has been reported by graywolf (Gray Wolf).

8 messages 2021/05/02

[#103724] [Ruby master Feature#17849] Fix Timeout.timeout so that it can be used in threaded Web servers — duerst@...

Issue #17849 has been reported by duerst (Martin Dst).

22 messages 2021/05/05

[#103756] [Ruby master Feature#17853] Add Thread#thread_id — komamitsu@...

Issue #17853 has been reported by komamitsu (Mitsunori Komatsu).

11 messages 2021/05/06

[#103801] [Ruby master Feature#17859] Start IRB when running just `ruby` — deivid.rodriguez@...

Issue #17859 has been reported by deivid (David Rodr刕uez).

18 messages 2021/05/12

[#103866] [Ruby master Bug#17866] Incompatible changes with Psych 4.0.0 — hsbt@...

Issue #17866 has been reported by hsbt (Hiroshi SHIBATA).

13 messages 2021/05/17

[#103892] [Ruby master Bug#17871] TestGCCompact#test_ast_compacts test failing again — jaruga@...

Issue #17871 has been reported by jaruga (Jun Aruga).

11 messages 2021/05/19

[#103912] [Ruby master Bug#17873] Update of default gems in Ruby 3.1 — hsbt@...

Issue #17873 has been reported by hsbt (Hiroshi SHIBATA).

38 messages 2021/05/20

[#103971] [Ruby master Bug#17880] [BUG] We are killing the stack canary set by `opt_setinlinecache` — jean.boussier@...

Issue #17880 has been reported by byroot (Jean Boussier).

8 messages 2021/05/22

[#103974] [Ruby master Feature#17881] Add a Module#const_added callback — jean.boussier@...

Issue #17881 has been reported by byroot (Jean Boussier).

29 messages 2021/05/22

[#104004] [Ruby master Feature#17883] Load bundler/setup earlier to make `bundle exec ruby -r` respect Gemfile — mame@...

Issue #17883 has been reported by mame (Yusuke Endoh).

21 messages 2021/05/24

[#104109] [Ruby master Feature#17930] Add column information into error backtrace — mame@...

Issue #17930 has been reported by mame (Yusuke Endoh).

34 messages 2021/05/31

[ruby-core:103725] [Ruby master Feature#17837] Add support for Regexp timeouts

From: duerst@...
Date: 2021-05-05 02:02:43 UTC
List: ruby-core #103725
Issue #17837 has been updated by duerst (Martin Dst).


Eregon (Benoit Daloze) wrote in #note-10:

> I think fixing Timeout.timeout might be possible.
> The main/major issue is it can trigger within `ensure`, right? Is there anything else?
> We could automatically mask `Thread#raise` within `ensure` so it only happens after the `ensure` body completes.
> And we could still have a larger "hard timeout" if an `ensure` takes way too long (shouldn't happen, but one cannot be sure).
> I recall discussing this with @schneems some time ago on Twitter.

I created a separate issue for the improvement of Timeout.timeout: #17849. Please feel free to discuss there. My guess is that there are all kinds of other issues that can happen in a Web application, so it would be better to solve this for the general case.

Dan0042 (Daniel DeLorme) wrote in #note-11:
> duerst (Martin Dst) wrote in #note-9:
> > I very strongly suggest that this feature be voluntary, e.g. as an additional flag on the regular expression.
> 
> If you have to turn it on for each regexp, that would make the feature kinda useless. I agree with the OP that this decision is at the application level.

I have no problems with making it possible to switch this on at the application level.

> You want it either on or off for all/most regexps. Although it would make sense to be able to override the default timeout for a few specific regexps that are known to be time-consuming or performance-critical.

Yes. My assumption is that when writing a regular expression, the writer should make sure it's well behaved. So in general, timeouts would only be needed for regular expressions that come from the outside.

> Rather than `CHECK_INTERRUPT_IN_MATCH_AT` would it be feasible to check for timeouts only when backtracking occurs?

In a backtracking regular expression engine, backtracking occurs very often. There are many cases of backtracking that are still totally harmless.

Ideally, a regular expression engine would deal with most regular expressions in a way similar to what RE2 (or any DFA-based implementation) does, and only use a timeout for those that a DFA-based strategy cannot handle (backreferences,...). But that would require quite a bit of implementation work.

(Of course all the above discussion is predicated on the assumption that timeouts cannot be added to regular expressions with negligible speed loss.) 

----------------------------------------
Feature #17837: Add support for Regexp timeouts
https://bugs.ruby-lang.org/issues/17837#change-91820

* Author: sam.saffron (Sam Saffron)
* Status: Open
* Priority: Normal
----------------------------------------
### Background

ReDoS are a very common security issue. At Discourse we have seen a few through the years. https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS

In a nutshell there are 100s of ways this can happen in production apps, the key is for an attacker (or possibly innocent person) to supply either a problematic Regexp or a bad string to test it with.

```
/A(B|C+)+D/ =~ "A" + "C" * 100 + "X"
```

Having a problem Regexp somewhere in a large app is a universal constant, it will happen as long as you are using Regexps. 


Currently the only feasible way of supplying a consistent safeguard is by using `Thread.raise` and managing all execution. This kind of pattern requires usage of a third party implementation. There are possibly issues with jRuby and Truffle when taking approaches like this.

### Prior art

.NET provides a `MatchTimeout` property per: https://docs.microsoft.com/en-us/dotnet/api/system.text.regularexpressions.regex.matchtimeout?view=net-5.0

Java has nothing built in as far as I can tell: https://stackoverflow.com/questions/910740/cancelling-a-long-running-regex-match

Node has nothing built in as far as I can tell: https://stackoverflow.com/questions/38859506/cancel-regex-match-if-timeout


Golang and Rust uses RE2 which is not vulnerable to DoS by limiting features (available in Ruby RE2 gem)

```
irb(main):003:0> r = RE2::Regexp.new('A(B|C+)+D')
=> #<RE2::Regexp /A(B|C+)+D/>
irb(main):004:0> r.match("A" + "C" * 100 + "X")
=> nil
```

### Proposal

Implement `Regexp.timeout` which allow us to specify a global timeout for all Regexp operations in Ruby. 

Per Regexp would require massive application changes, almost all web apps would do just fine with a 1 second Regexp timeout.

If `timeout` is set to `nil` everything would work as it does today, when set to second a "monitor" thread would track running regexps and time them out according to the global value.

### Alternatives 

I recommend against a "per Regexp" API as this decision is at the application level. You want to apply it to all regular expressions in all the gems you are consuming.

I recommend against a move to RE2 at the moment as way too much would break 


### See also: 

https://people.cs.vt.edu/davisjam/downloads/publications/Davis-Dissertation-2020.pdf
https://levelup.gitconnected.com/the-regular-expression-denial-of-service-redos-cheat-sheet-a78d0ed7d865





-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread