In message <52684f18.2000...@stemsystems.com>, you wrote:
>On 10/23/2013 06:18 PM, Ronald F. Guilmette wrote:
>
>> ...
>> print SM <<EOF;
>> To: "Tristatelogic.Com Administrator" <admin\@tristatelogic.com>
>> From: "$sender_name" <$sender_addr>
>> Subject: Your message to Tristatelogic.Com
>> X-Server-Protocol: $server_protocol
>> X-Http-User-Agent: $http_user_agent
>> X-Http-Referer: $http_referer
>> X-Remote-Addr: $remote_addr
>> X-Remote-Host: $remote_host
>>
>> $message
>>
>> EOF
>> ...
>>
>
>it isn't a here doc problem. they are just alternate ways of making
>strings and nothing special about them. also they don't need to use EOF
>for the token.
I am aware of that last part.
>> The puzzle is that I have received (in my admin inbox) two messages that
>> were clearly generated through and via the script that contains the above
>> code, *however* these two e-mail messages in particular, for some reason
>> *do* include the:
>>
>> To: "Tristatelogic.Com Administrator" <admin\@tristatelogic.com>
>>
>> header, and each one also includes a From: header, but then after that,
>> all the other headers that I had assumed would *always* be part of such
>> messages are not there... and it is quite apparent, because of the context,
>> that this must be because of the fact that the attacker who was looking for
>> exploits in my web site contact form kept on trying to put various quirky
>> and weird strings into the sender address data field in/on the form.
>
>so your email didn't get anything beyond the from: line?
That is correct.
>that is the big
>clue. email servers read headers until the first blank line.
I _do_ know more than a little about mail servers, and while you are
basically correct, i.e. that Postfix would certainly view anything
past the first \n\n encountered as being *message* data (not headers),
in the two messages in question, there was *nothing* in the way of body
text, other than a single "<" character.
Assuming your theory is correct and that the attacker was able to sneak
in a newline or two... into the input data constituting the sender name
or address fields... then it would still have been the case that within
the message body, I would have seen:
Subject: Your message to Tristatelogic.Com
X-Server-Protocol: bla bla bla
....
and so on. But I didn't! So there is still a deep mystery here.
>i bet the
>from field was filled with a string that had a newline in it (somehow).
See above. That would not adequantly explain this message:
===========================================================================
Return-Path: <nob...@tristatelogic.com>
X-Original-To: admin
Delivered-To: ad...@tristatelogic.com
Received: by segfault.tristatelogic.com (Postfix, from userid 80)
id C15FD3B403; Tue, 22 Oct 2013 04:42:59 -0700 (PDT)
To: "Monkeys.Com Administrator" <ad...@monkeys.com>
From: '@tristatelogic.com, "'\")"@tristatelogic.com;,
"|]*{"@tristatelogic.com
Message-Id: <20131022114259.c15fd3b...@segfault.tristatelogic.com>
Date: Tue, 22 Oct 2013 04:42:59 -0700 (PDT)
<
===========================================================================
>there may be another cause but it can't be a here doc as the data has no
>access to your code. something in the data caused the rest of the
>headers not to be processed by the mailer.
I believe that you may be on to something here, but it is more than just
Postfix seeing a \n\n and believeing that it had encountered the end of the
headers. It is possible that something in the input stream I gave it
signaled to it the end of *all* input (not just headers) but that is
still perplexing. What character or character sequence would do that?
I will have to dig into the Postfix docs and research that question.
I cannot imagine that it would stop reading stdin on anything other than
an actual EOF.
>> P.S. Don't bother trying to reproduce the exploit by putting weird stuff
>> into the contact form on my web site. I have revamped the contact form
>> handler script and have removed the "here" document it formerly contained
>> entirely.
>>
>it isn't the here doc but the data. it can't be the here doc. if you
>changed it to another string style the same exploit is there.
Well, I added to the script some rudimentary filtering/validation of
the input strings in question also.
Regards,
rfg
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
