On 2013-10-24 01:12, Ronald F. Guilmette wrote:
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.
Also test with strings with embedded 0-bytes.
--
Ruud
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
