On Fri, Dec 07, 2018 at 01:14:47PM +0100, Willy Tarreau wrote: > I had a quick look, some converters use check_operator() which creates > a variable upon each invocation of the parsing function. Some people > might inadvertently get caught by using these ones to look up cookie > values or session identifiers for example and not realize that zoombie > variables are lying behind. Another one is smp_check_const_bin() which > will call parse_binary(), returning an allocated memory block representing > the binary string, that nobody will free either. And for converters you > can see that all map-related functions use sample_load_map(), which will > attempt to load a file from the file system. Not only this must not be > attempted at run time for obvious performance reasons (will not work if > the config properly uses chroot anyway), but it may also use huge amounts > of memory on each call. That's a horrible side-effect for functions that are intended to validate arguments to functions.
- Should we introduce a field into sample_conv/sample_fetch that describes if the argument validation has side-effects? - Can we improve the fetch/conv to not have side-effects, or at least cleanup afterwards? Here's my validation of each of the checks so far. safe: sample_conv_json_check sample_conv_regsub_check sample_conv_field_check _51d_conv_check val_distcc val_payload_lv val_hdr smp_check_const_bool smp_check_const_meth unsafe: check_operator -> vars_check_arg -> register_name smp_check_concat -> vars_check_arg -> register_name smp_check_strcmp -> vars_check_arg -> register_name sample_load_map -> (it's a messy) conv_check_var -> vars_check_arg -> register_name smp_check_const_bin -> parse_binary -> ?? -- Robin Hugh Johnson E-Mail : robb...@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
signature.asc
Description: Digital signature
