Fix stack overflow when parsing variables

[gozzy]

For instance, a crash occured when HOME_NET is specified as $HOME_NET

[inliniac]

Can you explain the problem in a bit more detail? Create some example rules that crash for you?

[gozzy]

Actually it occurs in case of misconfiguration. For instance, if in yaml-file we specify the following:

vars:
HOME_NET: "!$HOME_NET"

It's definitely wrong configuration, but suricata recursively tries to resolve a variable in DetectAddressParse2() until stack is exhausted and segmentation fault occurs. Valgrind shows this:

==11392== Stack overflow in thread #1: can't grow stack to 0xffe801000
==11392==
==11392== Process terminating with default action of signal 11 (SIGSEGV)

I'm not sure if it's the best way to handle this misconfiguration... Furthermore, we can do something like this:

vars:
HOME_NET: "$EXTERNAL_NET"
EXTERNAL_NET: "$HOME_NET"

This is more complicated case, and it also leads to segmentation fault.

I've tried to handle this just to inform a user that something goes wrong. Because getting SIGSEGV without any details is not that good.

[inliniac]

I see, thanks. Could you open a redmine ticket for this bug as well? Thanks!

[gozzy]

Done: https://redmine.openinfosecfoundation.org/issues/1689

I'll try to look at the second case (when A is defined as B and vice versa).

[gozzy]

@inliniac probably we should just limit the recursion depth without tricky strings comparison.

[gozzy]

Got an idea about possible 'loop detection', gonna check it.