Re: Bash regexp parsing would benefit from safe recursion limit
willi1337 bald writes: > A deeply nested and incorrect regex expression can cause exhaustion of > stack resources, which crashes the bash process. Further, you could construct a deeply nested regex that is correct but would still crash the process. It's hard to define what should happen in a way that is implementable -- there are innumerable programs that are theoretically correct but exhaust the stack if you try to execute them. More or less what you want is some sort of "checkpoint" of the status of the overall computation (shell process) that you would return to. (a continuation!) Your suggestion is effectively that the checkpoint is "when bash prompts for the next command". But in a sense, that's what crashing the process is, too -- you return to the checkpoint "before you started the shell". If you had to worry about this in practice, you'd turn $ command1 $ command2 $ command3 into $ bash -c command1 $ bash -c command2 $ bash -c command3 Dale
Re: Bash regexp parsing would benefit from safe recursion limit
On 3/30/22 7:48 PM, Steffen Nurpmeso wrote: Chet Ramey wrote in : |On 3/30/22 11:16 AM, willi1337 bald wrote: |> Bash Version: 5.1 |> Patch Level: 16 |> Release Status: release |> |> Description: |> |> A deeply nested and incorrect regex expression can cause exhaustion of |> stack resources, which crashes the bash process. | |Bash doesn't use it's own regexp engine; it uses whatever POSIX regexp |functions are provided by the C library (regcomp/regexec/regfree/regerror). Once there was that ???FTP CVE regarding recursion, what they did was simply counting *'s in the expression string, and restricting it to three occasions per expression. That seems arbitrary and limiting. I'd rather see any `fix' for this kind of incorrect regexp come in the library functions themselves. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash regexp parsing would benefit from safe recursion limit
Chet Ramey wrote in : |On 3/30/22 11:16 AM, willi1337 bald wrote: |> Bash Version: 5.1 |> Patch Level: 16 |> Release Status: release |> |> Description: |> |> A deeply nested and incorrect regex expression can cause exhaustion of |> stack resources, which crashes the bash process. | |Bash doesn't use it's own regexp engine; it uses whatever POSIX regexp |functions are provided by the C library (regcomp/regexec/regfree/regerror). Once there was that ???FTP CVE regarding recursion, what they did was simply counting *'s in the expression string, and restricting it to three occasions per expression. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Bash regexp parsing would benefit from safe recursion limit
On 3/30/22 11:16 AM, willi1337 bald wrote: > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > Description: > > A deeply nested and incorrect regex expression can cause exhaustion of > stack resources, which crashes the bash process. Bash doesn't use it's own regexp engine; it uses whatever POSIX regexp functions are provided by the C library (regcomp/regexec/regfree/regerror). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash regexp parsing would benefit from safe recursion limit
On Wed, Mar 30, 2022 at 7:47 PM Martin Schulte wrote: > Hello Willi! > > > Fix: > > Count the stack frames during recursive parsing and emit error before > stack > > resources are entirely consumed. > > What exactly should happen and what is the benefit of this solution? > i guess it wont segfault anymore .. > > BTW: I tried > > trap 'echo "Ohohoh..."; exit 1;' SIGSEGV > > but the signal wasn't caught (which didn't really surprise me). > > Best regards > > Martin > >
Re: Bash regexp parsing would benefit from safe recursion limit
Hello Willi! > Fix: > Count the stack frames during recursive parsing and emit error before stack > resources are entirely consumed. What exactly should happen and what is the benefit of this solution? BTW: I tried trap 'echo "Ohohoh..."; exit 1;' SIGSEGV but the signal wasn't caught (which didn't really surprise me). Best regards Martin
Bash regexp parsing would benefit from safe recursion limit
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -Wno-parentheses -Wno-format-security
uname output: Linux DESKTOP-0TQV3NS 5.10.60.1-microsoft-standard-WSL2 #1
SMP Wed Aug 25 23:20:18 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
A deeply nested and incorrect regex expression can cause exhaustion of
stack resources, which crashes the bash process.
Repeat-By:
$ cat regexsegfault.sh ; gdb -q --args ./bash regexsegfault.sh
#!/bin/bash
A=$(printf "%32768s");
A=${A// /(}
[[ "B" =~ $A ]]
Reading symbols from ./bash...
(gdb) r
Starting program: /mnt/c/Users/Admin/bash-5.1.16/bash ../regexsegfault.sh
[Detaching after fork from child process 13645]
Program received signal SIGSEGV, Segmentation fault.
0x77e808ad in parse_expression (regexp=regexp@entry=0x7fffd880,
preg=preg@entry=0x7fffd980, token=token@entry=0x7fffd870,
syntax=syntax@entry=242428,
nest=nest@entry=10914, err=err@entry=0x7fffd868) at regcomp.c:2249
2249regcomp.c: No such file or directory.
(gdb) bt
#0 0x77e808ad in parse_expression (regexp=regexp@entry=0x7fffd880,
preg=preg@entry=0x7fffd980, token=token@entry=0x7fffd870,
syntax=syntax@entry=242428,
nest=nest@entry=10914, err=err@entry=0x7fffd868) at regcomp.c:2249
#1 0x77e83931 in parse_branch (regexp=regexp@entry=0x7fffd880,
preg=preg@entry=0x7fffd980, token=token@entry=0x7fffd870,
syntax=syntax@entry=242428,
nest=nest@entry=10914, err=err@entry=0x7fffd868) at regcomp.c:2207
#2 0x77e83b66 in parse_reg_exp (regexp=regexp@entry=0x7fffd880,
preg=preg@entry=0x7fffd980, token=token@entry=0x7fffd870,
syntax=syntax@entry=242428,
nest=nest@entry=10914, err=err@entry=0x7fffd868) at regcomp.c:2159
#3 0x77e80949 in parse_sub_exp (err=0x7fffd868, nest=10914,
syntax=242428, token=0x7fffd870, preg=0x7fffd980,
regexp=0x7fffd880) at regcomp.c:2496
#4 parse_expression (regexp=regexp@entry=0x7fffd880,
preg=preg@entry=0x7fffd980,
token=token@entry=0x7fffd870, syntax=syntax@entry=242428,
nest=nest@entry=10913,
err=err@entry=0x7fffd868) at regcomp.c:2282
Fix:
Count the stack frames during recursive parsing and emit error before stack
resources are entirely consumed.
