5 ms·

They seem to be fuzzing the regex, not just the input it is applied to. This may or may not change the results, but if you're allowing users to input arbitrary

They seem to be fuzzing the regex, not just the input it is applied to. This may or may not change the results, but if you're allowing users to input arbitrary regex patterns you have a whole lot of other problems.

gcp 10y ago
Huh? It would be perfectly valid to have it power the regex part of the scripting engine in a browser, for example. If that would then lead to memory safety errors, you just got yourself a 0-day. Regex engines used in browsers are both fast and hardened against these attacks.
- Houshalter 10y ago
  Finding vulnerabilities in existing regexes would be significantly more dangerous/interesting though. Like say if an exploit was found that could be triggered with a carefully crafted input to an email validator. Half of the servers on the web would be vulnerable! See e.g. https://en.wikipedia.org/wiki/ReDoS https://en.wikipedia.org/wiki/ReDoS If you have to be able to run an arbitrary regex on the victim's machine, that makes it much more limited. You shouldn't be letting users access regex any more than you should let them execute arbitrary code. Sure browsers do both of those things. But only through monumental effort that shouldn't be expected everywhere else.
AgentME 10y ago
I've seen plenty of places that you may want to accept an arbitrary regex from the user. An app could allow the user to set up a filter for messages or usernames by putting in a regex. Or an interpreter for a sandboxed language could provide regex support.
- revelation 10y ago
  All manner of problems in the programmers mind become trivial if only we allow users to input essentially code to express exactly what they want. Of course this is basically never a good solution. The issue with allowing arbitrary regex patterns is DoS through exponential blowup. But if you allow running code anyway you might not very much care for that.
  - kbenson 10y ago
    Assuming untrue things about the mathematical properties of your regular expression engine which are not supported by the documentation and allowing that to be exploited by user input is a different beast entirely than a bug in that library. The first, with careful examination of the properties may be preventable through sanitation of the input to exclude certain edge cases. You can't assume you'll be able to sanitize input ahead of time for bugs nobody knows about yet, which might be hidden in normally safe features.
  - Someone1234 10y ago
    DoS's can be limited by isolating the regular expression from the rest of the program and limiting its resource utilisation.
- kuschku 10y ago
  Or the ignore rule in an IRC client. The input pattern of a log filter. Etc.
Someone1234 10y ago
> if you're allowing users to input arbitrary regex patterns you have a whole lot of other problems. Why? I am legitimately asking, you say that like it is meant to be obvious or common knowledge. But many regular expression engines are self contained entities that can crash but cannot expose information or poison other parts of the program. A DoS-like attack might be an argument against unfettered user inputed regular expressions. But that off the top of my head is the only BIG risk. Particularly in secure-by-design languages like Java, C#, and Rust.
- Twirrim 10y ago
  It would be easy to create a regex that consumes a lot of CPU power. It's very difficult to vet a regex in an automated fashion.
  - Someone1234 10y ago
    Then don't vet it. Just run it as is, and limit how many local resources it can consume (CPU cycles and RAM). Then add on a timeout for good measure, and you are good to go.
    - ZoFreX 10y ago
      Alternatively, where possible, use a regular expression engine that does not have that issue: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html
- ZoFreX 10y ago
  Allowing users to enter regular expressions is definitely something that should only be entered into with caution. It is effectively code in a programming language that will be run, after all. For example, it means their input needs parsing - and parsing is very hard to get right and frequently results in exploitable bugs. There are also potential problems where regexps could take a very long time to execute, which could be a denial of service issue.

gcp 10y ago

Huh? It would be perfectly valid to have it power the regex part of the scripting engine in a browser, for example. If that would then lead to memory safety errors, you just got yourself a 0-day. Regex engines used in browsers are both fast and hardened against these attacks.

Houshalter 10y ago
Finding vulnerabilities in existing regexes would be significantly more dangerous/interesting though. Like say if an exploit was found that could be triggered with a carefully crafted input to an email validator. Half of the servers on the web would be vulnerable! See e.g. https://en.wikipedia.org/wiki/ReDoS https://en.wikipedia.org/wiki/ReDoS If you have to be able to run an arbitrary regex on the victim's machine, that makes it much more limited. You shouldn't be letting users access regex any more than you should let them execute arbitrary code. Sure browsers do both of those things. But only through monumental effort that shouldn't be expected everywhere else.

AgentME 10y ago

I've seen plenty of places that you may want to accept an arbitrary regex from the user. An app could allow the user to set up a filter for messages or usernames by putting in a regex. Or an interpreter for a sandboxed language could provide regex support.

revelation 10y ago
All manner of problems in the programmers mind become trivial if only we allow users to input essentially code to express exactly what they want. Of course this is basically never a good solution. The issue with allowing arbitrary regex patterns is DoS through exponential blowup. But if you allow running code anyway you might not very much care for that.
- kbenson 10y ago
  Assuming untrue things about the mathematical properties of your regular expression engine which are not supported by the documentation and allowing that to be exploited by user input is a different beast entirely than a bug in that library. The first, with careful examination of the properties may be preventable through sanitation of the input to exclude certain edge cases. You can't assume you'll be able to sanitize input ahead of time for bugs nobody knows about yet, which might be hidden in normally safe features.
- Someone1234 10y ago
  DoS's can be limited by isolating the regular expression from the rest of the program and limiting its resource utilisation.
kuschku 10y ago
Or the ignore rule in an IRC client. The input pattern of a log filter. Etc.

Someone1234 10y ago

> if you're allowing users to input arbitrary regex patterns you have a whole lot of other problems. Why? I am legitimately asking, you say that like it is meant to be obvious or common knowledge. But many regular expression engines are self contained entities that can crash but cannot expose information or poison other parts of the program. A DoS-like attack might be an argument against unfettered user inputed regular expressions. But that off the top of my head is the only BIG risk. Particularly in secure-by-design languages like Java, C#, and Rust.

Twirrim 10y ago
It would be easy to create a regex that consumes a lot of CPU power. It's very difficult to vet a regex in an automated fashion.
- Someone1234 10y ago
  Then don't vet it. Just run it as is, and limit how many local resources it can consume (CPU cycles and RAM). Then add on a timeout for good measure, and you are good to go.
  - ZoFreX 10y ago
    Alternatively, where possible, use a regular expression engine that does not have that issue: https://swtch.com/~rsc/regexp/regexp1.html https://swtch.com/~rsc/regexp/regexp1.html
ZoFreX 10y ago
Allowing users to enter regular expressions is definitely something that should only be entered into with caution. It is effectively code in a programming language that will be run, after all. For example, it means their input needs parsing - and parsing is very hard to get right and frequently results in exploitable bugs. There are also potential problems where regexps could take a very long time to execute, which could be a denial of service issue.