On Sat, Nov 17, 2012 at 5:18 PM, Phil Pennock <pdp@???> wrote:
>> Re the following bit of code (line 142) :
>> http://git.exim.org/users/tlyons/exim.git/blob/40367a0461cd662d081991d1edf2d891695ff255:/src/src/dmarc.c#l142
>
> An email address LHS can contain a $dollar, even without being in
> double-quotes. So the code as written is a security hole, because the
> address is injected directly into the string and is equivalent to "eval"
> of untrusted text. If you use $rh_From: instead, then the expansion
> only expands that $string to its value and won't recursively expand the
> content.
Use $rh_From instead of the printf and struct to directly access it.
That makes sense.
> An email address LHS can contain a colon, albeit in quotes, so the
> numeric extract will fail: it's geared for things like passwd files and
> doesn't use the doubling-to-escape convention. Perhaps:
Drats.
> Exim uses expand_string() in a few places, it's not too bad, but if you
Ok, that was the kind of answer I was not necessarily expecting, but
kinda hoping for. It does remove some complexity.
> If there's not, perhaps add it? "This function gets the local_part and
> domain of the first address in the first From: header of the message";
> between DMARC, DKIM, and other bits, I'm sure we could use it more than
> once. :)
Ah, string handling. There's nothing that can go wrong there...hehe,
yeah right. But I think I will approach it from this angle. There
are lots of good examples of string parsing littered through the exim
source, I'll test and see what I can do.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine