On Thu, Oct 23, 2014 at 09:39:24AM -0400, Wietse Venema wrote:
> > In all cases the historical one-action form still works as before.
>
> There is a small gotcha: the $number expansion in regexp and pcre
> table lookup results happens before {} parsing. This would make {}
> parsing dependent on the content of $number expansion, i.e. untrusted
> data, creating a command injection vulnerability.
I noticed the possibility when you sent the original message.
> - Or the $number expansion stays where it is now, before {} parsing,
> but the caller can specify a filter that censors out {} in $number
> expansions, so that the caller's command parser cannot be tricked
> into executing the wrong command. This extends the table API with
> one function that does nothing except for regexp and pcre tables.
It might alternatively make sense to allow escaping via "\{", "\}"
and "\\", and to signal the pcre/regexp drivers to apply such
escapes to interpolated strings.
> (Of course nothing in Postfix can protect against accidents caused
> by text manipulations inside a policy daemon; they would have to
> censor themselves, or Postfix would need an option to disable {}
> support for policy filter replies).
As for policy tables, it might be better to support multiple "action"
values in a single reply, though I understand that this may be
difficult to support in the current "attr_client" API, can
"ATTR_TYPE_FUNC" deal with repeated instances of the same attribute?
--
Viktor.
