Re: Help needed with here documents (security?)
Another way of handling is to use one of the availabe Email::* modules on CPAN. This would have the advantages of (beside you don't have to worry about details of string quoting): - better code, as you write down what you intend to do instead of how you do it - better security, as those modules already handles (hopefully) the security breaches - you don't have to think a lot of stuff other have already thought a lot about -- Don't Repeat Yourself or other ones For example [untested]: use Email::Simple; my $email = Email::Simple-create( header = [ From = $sender_addr, To = 'ad...@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, ], body = $message ); print $email-as_string; Greetings, Janek -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
On Thu, 24 Oct 2013 13:52:51 +0200 Janek Schleicher janek_schleic...@yahoo.de wrote: use Email::Simple; my $email = Email::Simple-create( header = [ From = $sender_addr, To = 'ad...@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, ], body = $message ); Why are you using an anonymous array for the header? Wouldn't an anonymous hash be better? A hash would insist on an even number of elements. -- Don't stop where the ink does. Shawn -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
On Oct 24, 2013, at 6:07 AM, Shawn H Corey wrote: On Thu, 24 Oct 2013 13:52:51 +0200 Janek Schleicher janek_schleic...@yahoo.de wrote: use Email::Simple; my $email = Email::Simple-create( header = [ From = $sender_addr, To = 'ad...@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, ], body = $message ); Why are you using an anonymous array for the header? Wouldn't an anonymous hash be better? A hash would insist on an even number of elements. According to the documentation for Email::Simple, an anonymous array is required for the header parameter of the create method. http://search.cpan.org/~rjbs/Email-Simple-2.202/lib/Email/Simple.pm#create Suggestions for improvement should be directed to the module's author (but you knew that, right?). -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
On Thu, 24 Oct 2013 06:30:58 -0700 Jim Gibson jimsgib...@gmail.com wrote: On Oct 24, 2013, at 6:07 AM, Shawn H Corey wrote: On Thu, 24 Oct 2013 13:52:51 +0200 Janek Schleicher janek_schleic...@yahoo.de wrote: use Email::Simple; my $email = Email::Simple-create( header = [ From = $sender_addr, To = 'ad...@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, ], body = $message ); Why are you using an anonymous array for the header? Wouldn't an anonymous hash be better? A hash would insist on an even number of elements. According to the documentation for Email::Simple, an anonymous array is required for the header parameter of the create method. http://search.cpan.org/~rjbs/Email-Simple-2.202/lib/Email/Simple.pm#create Suggestions for improvement should be directed to the module's author (but you knew that, right?). Well, the only reason to do that is to preserve the order. I didn't realize that email was that pernickety. -- Don't stop where the ink does. Shawn -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
Am 24.10.2013 15:07, schrieb Shawn H Corey:
my $email = Email::Simple-create(
header = [
From = $sender_addr,
To = 'ad...@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,
],
body = $message
);
Why are you using an anonymous array for the header? Wouldn't an
anonymous hash be better? A hash would insist on an even number of
elements.
I just followed the synopsis of the documentation of this CPAN-Module as
you can find it here: https://metacpan.org/pod/Email::Simple :-)
I agree to you, that a ref to a hash like header = { ... } would
somehow be more logic, but I didn't wrote this CPAN module.
Greetings,
Janek
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Help needed with here documents (security?)
From: Janek Schleicher janek_schleic...@yahoo.de
Am 24.10.2013 15:07, schrieb Shawn H Corey:
my $email = Email::Simple-create(
header = [
From = $sender_addr,
To = 'ad...@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,
],
body = $message
);
Why are you using an anonymous array for the header? Wouldn't an
anonymous hash be better? A hash would insist on an even number of
elements.
I just followed the synopsis of the documentation of this CPAN-Module as
you can find it here: https://metacpan.org/pod/Email::Simple :-)
I agree to you, that a ref to a hash like header = { ... } would somehow
be more logic, but I didn't wrote this CPAN module.
Aren't duplicate headers allowed in email headers?
Because if they are allowed, maybe this is the reason an arrayref is used,
and not a hashref.
Octavian
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 7E7181F2497441C88988DD1F16E4A743@octavianf303f0, you wrote:
From: Janek Schleicher janek_schleic...@yahoo.de
Am 24.10.2013 15:07, schrieb Shawn H Corey:
my $email = Email::Simple-create(
header = [
From = $sender_addr,
To = 'ad...@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,
],
body = $message
);
Why are you using an anonymous array for the header? Wouldn't an
anonymous hash be better? A hash would insist on an even number of
elements.
I just followed the synopsis of the documentation of this CPAN-Module as
you can find it here: https://metacpan.org/pod/Email::Simple :-)
I agree to you, that a ref to a hash like header = { ... } would somehow
be more logic, but I didn't wrote this CPAN module.
Aren't duplicate headers allowed in email headers?
Yes.
The vast majority of all the e-mail I have in my big piles of e-mails
has multiple Received: headers, in particular. And yes, order matters
with respect to interpreting those (but also it matters in the case of
other headres sometimes too.)
But, getting back to my original 2 questions...
I want to stress that I did not ask how to formulate and/or send a
properly formatted e-mail message. I can handle that part, even if
perhaps only in my own clumsey way.
What is of more interest to me, again, is the question of how to properly
validate (a) a string that's given on a form and which is meant to
represent a person's name, an also (b) a string that is given in a form
and that is supposed to represent a person's e-mail address.
Assume that I want to do both these things *and*, to the maximum extent
possible, I want to reject any all strings that are implausible name
and/or e-mail address strings.
How? What's the code to do each of these things.
These certainly should both be well-solved problems by now, but in case
they aren't, I'd like to take my own humble wack at developing good
solutions for both problems.
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Help needed with here documents (security?)
On Oct 24, 2013, at 11:59 AM, Ronald F. Guilmette wrote: But, getting back to my original 2 questions... I want to stress that I did not ask how to formulate and/or send a properly formatted e-mail message. I can handle that part, even if perhaps only in my own clumsey way. What is of more interest to me, again, is the question of how to properly validate (a) a string that's given on a form and which is meant to represent a person's name, an also (b) a string that is given in a form and that is supposed to represent a person's e-mail address. Assume that I want to do both these things *and*, to the maximum extent possible, I want to reject any all strings that are implausible name and/or e-mail address strings. How? What's the code to do each of these things. These certainly should both be well-solved problems by now, but in case they aren't, I'd like to take my own humble wack at developing good solutions for both problems. See the advice in Perl FAQ #9 How do I check a valid mail address? The command 'perldoc -q address' will get you that entry. Synopsis: it is difficult to write a regular expression to parse and validate an email address. The modules Email::Valid and RFC::RFC822::Address might help. I usually just check to see if the string contains the '@' character. I might also delete any character that is not in [a-zA-Z0-9.:;_@-] (but see the longer RE in the FAQ). -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
Ronald F. Guilmette wrote: In message5268663c.4040...@stemsystems.com, Uri Guttmanu...@stemsystems.comwrote: i think a blank line with . will end input to smtp servers. try that too in the line after the from field. DING DING DING!!! Give that man a cupie doll, because he's the winner of today's perplexing puzzle test! In short, yes, when I first read the above sentence, I said to myself No way! I know that when input is coming in ``over the wire'' to a normal SMTP server *and* when it is already in ``DATA'' (input message collection) SMTP protocol mode, *then* a period alone on a line ends input, *however* in this case Postfix is reading the message from STDIN, and so there is really no need for that period-alone-on-a-line bit of SMTP protocol to apply in this case, because EOF in this case can be signalled by... well... an actual EOF, of course! stdin (and stdout) are part of a stream protocol and as such are not about files and do not signal End-Of-File which is part of why emails use the single period to signal the end of the message. John -- Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. -- Albert Einstein -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
On Thu, 24 Oct 2013 14:55:51 -0700 John W. Krahn jwkr...@shaw.ca wrote: stdin (and stdout) are part of a stream protocol and as such are not about files and do not signal End-Of-File which is part of why emails use the single period to signal the end of the message. I thought that was from the old mail(1) program. To indicate to it that you were done typing your message and it could send it, you typed a single period on a line. And all streams have end of file. -- Don't stop where the ink does. Shawn -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 52699767.2050...@shaw.ca, you wrote: Ronald F. Guilmette wrote: In message5268663c.4040...@stemsystems.com, Uri Guttmanu...@stemsystems.comwrote: i think a blank line with . will end input to smtp servers. try that too in the line after the from field. DING DING DING!!! Give that man a cupie doll, because he's the winner of today's perplexing puzzle test! In short, yes, when I first read the above sentence, I said to myself No way! I know that when input is coming in ``over the wire'' to a normal SMTP server *and* when it is already in ``DATA'' (input message collection) SMTP protocol mode, *then* a period alone on a line ends input, *however* in this case Postfix is reading the message from STDIN, and so there is really no need for that period-alone-on-a-line bit of SMTP protocol to apply in this case, because EOF in this case can be signalled by... well... an actual EOF, of course! stdin (and stdout) are part of a stream protocol and as such are not about files and do not signal End-Of-File which is part of why emails use the single period to signal the end of the message. I'm not sure that I can even properly parse what you just said, but if I am parsing what you said correctly, then I disagree. C language stdio streams _do_ most definietly signal EOF. See: man 3 feof In the case of *bi-directional* network *sockets* used for SMTP transactions however, it is necessary to use some sort of in-band signaling (i.e. the period alone on a line) to signal the end of the message text, because after that, the socket must remain open so that the client can receive back and then properly interpret and react to whatever following XXX numeric response code the server decides to send back, just after the client has sent the end-of-message indicator. But when Postfix is reading a message from stdin, and when it gets to the end of the message... well, there isn't any more interaction, and in fact their could not be, because this is just uni-directional data flow. The message comes in on Postfix's stdin and then its done and that's it. So in this case, to my way of thinking at least, it is downright nonsensical that in this context Postfix is even looking for (or recognizing) the specialized in-band end-of-message indicator that, of necessity, had to be invented for and used with by-directional SMTP transactions/conversations. Sigh. I'll would wager that Wietse probably feels the same way, but that, as is often the case, he was constrained by the need to implement odd bits of behavior like this in order to be maximally compatible with the pre-existing Sendmail behavior. :-( Anyway, I'll be asking about this.. on the appropriate mailing list, of course. (It just feels wrong to me, and is definitely *not* what I would call ``intutive'' behavior.) Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 20131024183255.3c233104@sage, you wrote: On Thu, 24 Oct 2013 14:55:51 -0700 John W. Krahn jwkr...@shaw.ca wrote: stdin (and stdout) are part of a stream protocol and as such are not about files and do not signal End-Of-File which is part of why emails use the single period to signal the end of the message. I thought that was from the old mail(1) program. To indicate to it that you were done typing your message and it could send it, you typed a single period on a line. And all streams have end of file. Yes. And in my setup, at least, EOF can be signaled from the keyboard with the (traditional?) ^D. Obviously, that could be used, e.g. in cases where somebody wants to interactively type a mail message into some mail client that lacks a front-end editor of any kind. I don't see any need for this in-band period/newline protocol within such contexts. (And as I have now learned, it can cause unnecessary and not entirely pleasant surprises.) Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
From: Ronald F. Guilmette r...@tristatelogic.com
In message 7E7181F2497441C88988DD1F16E4A743@octavianf303f0, you wrote:
From: Janek Schleicher janek_schleic...@yahoo.de
Am 24.10.2013 15:07, schrieb Shawn H Corey:
my $email = Email::Simple-create(
header = [
From = $sender_addr,
To = 'ad...@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,
],
body = $message
);
Why are you using an anonymous array for the header? Wouldn't an
anonymous hash be better? A hash would insist on an even number of
elements.
I just followed the synopsis of the documentation of this CPAN-Module as
you can find it here: https://metacpan.org/pod/Email::Simple :-)
I agree to you, that a ref to a hash like header = { ... } would somehow
be more logic, but I didn't wrote this CPAN module.
Aren't duplicate headers allowed in email headers?
Yes.
The vast majority of all the e-mail I have in my big piles of e-mails
has multiple Received: headers, in particular. And yes, order matters
with respect to interpreting those (but also it matters in the case of
other headres sometimes too.)
But, getting back to my original 2 questions...
I want to stress that I did not ask how to formulate and/or send a
properly formatted e-mail message. I can handle that part, even if
perhaps only in my own clumsey way.
What is of more interest to me, again, is the question of how to properly
validate (a) a string that's given on a form and which is meant to
represent a person's name, an also (b) a string that is given in a form
and that is supposed to represent a person's e-mail address.
Assume that I want to do both these things *and*, to the maximum extent
possible, I want to reject any all strings that are implausible name
and/or e-mail address strings.
How? What's the code to do each of these things.
These certainly should both be well-solved problems by now, but in case
they aren't, I'd like to take my own humble wack at developing good
solutions for both problems.
I think that what you want is not possible. :-)
I mean, I don't think it is possible to create a rule that simply filters out
all strings which can't be names or all strings that can't be email addresses,
without filtering out good names and email addresses, of course.
There are many language scripts that can be use to write the names with, and
that filter should not filter the names written with
chinese/japanese/arabic/kirilic/hebrew and many other exotic scripts used with
8-bit encodings or with Unicode.
If you just want to filter the names which are not English-like names, you can
deny anything which is not [a-zA-Z0-9\s.'-].
If you want to also allow some Unicode letters and not only A-Za-z, you can use
\p{L} or \p{Letter} instead of A-Za-z.
But there may be strange chars composed from a letter followed one or more
diacritic signs, so the regexp may need to be more complex.
Regarding the email addresses... the RFCs allow many types of email addresses
which are almost never used now.
I don't know if there is a current RFC or standard that defines the rules for
an email address which is currently used by most email services. The filter
could be based on that rule, but it might filter out some valid exotic email
addresses. On the other hand, if the existing rules are used, they may allow
strings which look like a valid email address, even if that kind of email
address is not used by nobody these days.
So these filters could be strict and allow only the most expected name and
email formats, but they might disallow some valid emails and names, or they can
accept all the possible formats (like Email::Valid does in case of an email
address), but then you can get strange formats that your software can't handle.
It could be helpful if you'd have the rules for the email formats accepted by
your email server.
If the email addresses follow that rule it means that they are OK. If they
don't follow it, then it doesn't matter that the addresses are valid, because
they can't be handled anyway.
Octavian
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 39517.1382566...@server1.tristatelogic.com, I wrote: About a day ago, some schmuck set about to try, hard, to exploit the personally written Perl code I have in place and that processes the input for the contact form on my web site... I neglected to mention that this was obviously nothing personal. Many of the messages I did get as a result of these exploit attempts contained the string 3137 LagunaStreet. A google of that exact string, quoted, turns up: 1) A probably entirely unrelated and innocent Real Estate firm in San Francisco, and... 2) ... more than 125K hits having something to do with this same schmuck going around making attempts to exploit other forms on other people's web sites, clearly with evil, if not to say criminal intent. (Some of the hits suggest that this is just a comment spammer, but the messages I did get via my not-actually- exploited contact form on my web site indicate clearly that he was trying hard to lay hands on my /etc/passwd file, and I rather doubt that mere comment spammers do that.) Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
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. 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 the big clue. email servers read headers until the first blank line. i bet the from field was filled with a string that had a newline in it (somehow). 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. 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. uri -- Uri Guttman - The Perl Hunter The Best Perl Jobs, The Best Perl Hackers http://PerlHunter.com -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
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/
Re: Help needed with here documents (security?)
On Wed, 23 Oct 2013 16:12:12 -0700 Ronald F. Guilmette r...@tristatelogic.com wrote: 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? Sometimes if the string has a null character, \0, it won't read pass it. This, of course, is a bug but determining what piece of software is doing it will be difficult. -- Don't stop where the ink does. Shawn -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
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/
Re: Help needed with here documents (security?)
On 10/23/2013 07:12 PM, Ronald F. Guilmette wrote: In message 52684f18.2000...@stemsystems.com, you wrote: 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. i think a blank line with . will end input to smtp servers. try that too in the line after the from field. === 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. Well, I added to the script some rudimentary filtering/validation of the input strings in question also. you need more than rudimentary filtering. make sure the from field is one string, no newlines or anything but printable text. uri -- Uri Guttman - The Perl Hunter The Best Perl Jobs, The Best Perl Hackers http://PerlHunter.com -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 20131023193228.38cf83e2@sage, you wrote: On Wed, 23 Oct 2013 16:12:12 -0700 Ronald F. Guilmette r...@tristatelogic.com wrote: 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? Sometimes if the string has a null character, \0, it won't read pass it. This, of course, is a bug but determining what piece of software is doing it will be difficult. Actually, I think now that something _other than_ a mere null byte is causing Postfix to get a bit confused, but as regards to what piece of software is losing its way, it is most definitely Postfix, since my Perl script is piping data directly into that. Anyway, just a few moments ago I realized/remembered that Postfix is trying to _parse_ the headers it is given. This is part of its job... so that it can do wonderful and useful things, like as attaching @domain to (local) e-mail addresses that don't already have that. So anyway, I also then realized that yes, Postfix's parsing of the From: header(s) contained within the data I was feeding it probaby failed, utterly, and *not* because there's any actual ``fault'' in Postfix, but rather because the gobbledegook that my attacker was putting into the web contact form didn't add up to anything that actually constituted anything like an even remotely parseable e-mail address, according to current RFC rules. So this is my current/new theory, i.e. that the attacker _didn't_ actually manage to compromise me or execute any code on my system, but that he _did_ manage to pass in some really twisted and sick strings (where there should have been either a person's name or a person's e-mail address) and then Postfix, perhaps not surprisingly, wasn't able to parse that, and as a result it threw up its hands (in disgust?) after one too many parsing errors. Well, it's a theory anyway. I hope it is correct, because it is making me feel better already. (I *was* seriously* worried that I had been compromised, even if only slightly. Even executing only under the rather limited local `www' account/user, an unauthorized outsider could undoubtedly do a lot of mischief that I wouldn't like.) Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 5268663c.4040...@stemsystems.com, Uri Guttman u...@stemsystems.comwrote: i think a blank line with . will end input to smtp servers. try that too in the line after the from field. DING DING DING!!! Give that man a cupie doll, because he's the winner of today's perplexing puzzle test! In short, yes, when I first read the above sentence, I said to myself No way! I know that when input is coming in ``over the wire'' to a normal SMTP server *and* when it is already in ``DATA'' (input message collection) SMTP protocol mode, *then* a period alone on a line ends input, *however* in this case Postfix is reading the message from STDIN, and so there is really no need for that period-alone-on-a-line bit of SMTP protocol to apply in this case, because EOF in this case can be signalled by... well... an actual EOF, of course! But then, just to be sure, I tried it myself, and lo and behold, Postfix *does* apparently treat period-on-a-line-alone as the end of the input message data, *even when* it is reading the message from STDIN (which, to my way of thinking, is _totally_ bizzare, unnecessary, and certainly un- expected). So thanks! This clears up the mystery pretty completely, I think. The attacker no doubt used the HTTP %xx notation to smugle in some newlines, and also stuck a period in there somewhere, and that would completely explain the content of the two exceptionally mysterious messages I saw. (Thankfully, all this means that I was _most probably_ never actually security compromised in any way.) Well, I added to the script some rudimentary filtering/validation of the input strings in question also. you need more than rudimentary filtering. make sure the from field is one string, no newlines or anything but printable text. Um, yes, sorry. I failed to make my meaning plain. When I said rudimentary filtering of the input strings, what I really had intended to say was that I implemented quick and dirty filtering of the strings in question that is grotesquely *over*-restrictive in each case. (The input validation steps for both name and e-mail address *should*, ideally, be much looser than what I have now, but I am too busy just now to deal with it.) For example, if you try *now* to use my contact form and if you try to use any ``funny'' characters at all in either your name or your e-mail address, the current data collection script will basically refuse that data and then tell you to try again. (I hope that nobody from Europe who has umlauts or grave accents in the correct spellings of their names needs to use that form to contact me anytime soon. :-) Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: Help needed with here documents (security?)
In message 40504.1382576...@server1.tristatelogic.com, I wrote: Well, I added to the script some rudimentary filtering/validation of the input strings in question also. you need more than rudimentary filtering. make sure the from field is one string, no newlines or anything but printable text. Um, yes, sorry. I failed to make my meaning plain. When I said rudimentary filtering of the input strings, what I really had intended to say was that I implemented quick and dirty filtering of the strings in question that is grotesquely *over*-restrictive in each case. (The input validation steps for both name and e-mail address *should*, ideally, be much looser than what I have now, but I am too busy just now to deal with it.) For example, if you try *now* to use my contact form and if you try to use any ``funny'' characters at all in either your name or your e-mail address, the current data collection script will basically refuse that data and then tell you to try again. (I hope that nobody from Europe who has umlauts or grave accents in the correct spellings of their names needs to use that form to contact me anytime soon. :-) As a hypothetical, assume for the moment that one day I will have time to implement the validation of the input strings ``properly''. Does anyone wnat to pass me a free clue or two as to how I might do this? The contact form is *really* simple: http://www.tristatelogic.com/contact2.html I know that parsing e-mail address _properly_, i.e. according to all current RFC rules can be really rather complex, so I'll start by looking around to see if there is some existing off-the-shelf Perl package that will do this for me. (Anybody know which one I should be looking at on CPAN?) And I also know that if I want to be really persnickety, I'll even check the domain name part to make sure it has either an associated MX or A record in DNS. I may do that too, but I don't need any help for that, because I already know my way around the DNS:: stuff. As regards to the (person's) name data, can anybody suggest a good and proper filter for that? I'd like it to reject any string that contains *any* characters that simply do not ever belong in a person's name... not just newlines and such. For example, I don't know anybody who writes their name with a (US) dollar sign or exclamation point or a asterisk, or most other special characters. But I don't really know poo about international character sets or how to handle them properly, so I really have no idea how to even start working on a ``proper'' filter for the name string. Any helpful tips would be appreciated. Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
