CGIemail spam exploit - solution?
Matt Cohen
has anyone found a solution to the following cgiemail spam exploit:
http://msgs.securepoint.com/cgi-bin/get/bugtraq0206/113/1.html
Contrary to what the article says, it is NOT hard to exploit.
lets say I have a template for a form where the users' email is set as
the from: address of the resulting form email. i.e. the headers are:
TO: m...@mydomain.com
From: [email]
Subject: this is a cgiemail generated email
If you use a %0a (newline) character in your form submission of your
email address you could insert another line into the headers of the
email - including Bcc:, cc: etc,
So in the above example, assuming a valid template with the above
headers,
Works just peachy keen to send an email to someoth...@yahoo.com,
of course looking like it came from mye...@hotmail.com
This exploit works on ANY cgiemail form where any of the form fields
are reproduced in ANY header of the template file. i.e. if your
subject is taken from a form field, then you are vulnerable.
The only fix I can see is to strip out that character somehow in the
processing of the script, but not being a C programmer, i'm not sure
how that would be done.
Any one else find a solution to this or do I have to take all my form
fields out of all my template headers?
Thanks,
Matt
--
PLEASE NOTE: comp.infosystems.www.authoring.cgi is a
SELF-MODERATED newsgroup. aa.net and boutell.com are
NOT the originators of the articles and are NOT responsible
for their content.
HOW TO POST to comp.infosystems.www.authoring.cgi:
http://www.thinkspot.net/ciwac/howtopost.html
Sheila King
comp.infosystems.www.authoring.cgi in article
<cda630b5.02110...@posting.google.com>:
Matt,
I cannot comment on bugfixes for cgiemail regarding this type of exploit.
However, I have written a similar script which prevents this type of
exploit. Just FYI:
http://www.thinkspot.net/sheila/computers/software/gypsymail.html
Basically, the script checks whether someone has tried to insert To, Cc,
or Bcc fields into the submitted form data.
There's nothing particularly clever about it. I'm sure that it wouldn't be
hard for cgiemail to do a similar check. I just don't code in C, so
wouldn't exactly be able to suggest the fix myself.
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/
Sheila King
in comp.infosystems.www.authoring.cgi in article
<aqhau7...@kserver.org>:
>
> Basically, the script checks whether someone has tried to insert To, Cc,
> or Bcc fields into the submitted form data.
Actually, let me be more specific...
It check so for the occurrence of:
"\nTo:"
"\nCc:"
"\nBcc:"
and the checks are case-insensitive.
William Alexander Segraves
news:cda630b5.02110...@posting.google.com...
> I did a search on the archives and didn't see any mention of it here -
> has anyone found a solution to the following cgiemail spam exploit:
>
> http://msgs.securepoint.com/cgi-bin/get/bugtraq0206/113/1.html
>
> Contrary to what the article says, it is NOT hard to exploit.
>
> lets say I have a template for a form where the users' email is set as
> the from: address of the resulting form email. i.e. the headers are:
>
> TO: m...@mydomain.com
> From: [email]
> Subject: this is a cgiemail generated email
MindSpring (EarthLink), in its "Using Email Forms on Your Web Pages", states
"For security reasons, do not include any variables (bracketed words) in any
of header items ..."
This is good advice, as it prevents the subject exploit.
OTOH, if you _must_ use cgiemail for form processing, it is a good idea to
at least include your own E-mail address hard-coded in the "To:" field.
While this will not prevent the subject exploit, you will know when the
template is exploited, as a copy of any spam exploit will be sent to the
hard-coded "To:" address.
Bill Segraves
William Alexander Segraves
news:aqjde7$ku9$1...@slb6.atl.mindspring.net...
<snip>
> MindSpring (EarthLink), in its "Using Email Forms on Your Web Pages",
states
> "For security reasons, do not include any variables (bracketed words) in
any
> of header items ..."
>
> This is good advice, as it prevents the subject exploit.
>
> OTOH, if you _must_ use cgiemail for form processing,
[In my previous, I should have stated]
with any form variables included in the headers,
Sheila King
in comp.infosystems.www.authoring.cgi in article
<ingjqa...@jarl.webthing.com>:
> In article <aqhb7t...@kserver.org>, one of infinite monkeys
> at the keyboard of Sheila King <use...@thinkspot.net> wrote:
> > It check so for the occurrence of:
> >
> > "\nTo:"
> >
> > "\nCc:"
> >
> > "\nBcc:"
>
> Even simpler, jsut check for any newline. That way you don't have to
> RTFM in detail for all the more obscure headers concerning forwarding
> or return-to-sender mail.
True, but you can't just check for any newline, as some of the form
elements (like the text areas for entering the text of an email message
body) must allow for newline characters.
My particular script only recognizes the above three fields for sending out
mail. The script grabs the contents of those fields and forms the SMTP
envelope recipient list from them, and uses SMTP protocol to deliver the
message. So, at least in my case, the above check is sufficient, as any
other obscure RFC headers would not be recognized.
In the case of cgiemail, that probably doesn't apply, however.
I suppose checking for a newline character, following by some alphanumeric
characters containing possible underscores and/or dashes, with a colon and
then a blank space would be a bit better, but this still causes
difficulties under some circumstances in a large text area form object, as
it would give error messages for perfectly valid content in the message
body.
> If found, you could either print a "thod off, thpammer" error message
> or simply insert a space directly after the newline (so that it
> becomes a continuation of the previous header, which is one of your
> preset ones and therefore legit).
>
> > --
>
> Eeek, that's not a sig separator. Surely you know better?
Yes, I do. Unfortunately, Agent Newsreader didn't used to. Used to not
allow saving sig files with trailing spaces. However, I've upgraded since
then (been using this proggie for a LONG time), and apparently it does now
allow trailing spaces in sig files. I've updated all my sig files. This one
should be better now.
Pete Wilson
> "William Alexander Segraves" <wseg...@mindspring.com> wrote in message
> news:aqjde7$ku9$1...@slb6.atl.mindspring.net...
> <snip>
> > MindSpring (EarthLink), in its "Using Email Forms on Your Web Pages",
> states
> > "For security reasons, do not include any variables (bracketed words) in
> any
> > of header items ..."
> [In my previous, I should have stated]
>
> with any form variables included in the headers,
Sorry if I'm restating the obvious.
I'm starting to believe that every CGI script does/can/should know up
front to whom to send every form-submitted email, without exception.
So perhaps it's OK, and maybe required, simply to discard all
submitted email headers and construct, in the script, my own recipient
headers from scratch. Then I can filter "subject:" and I can put
"from:" into the /body/ of the email where it threatens smaller harm.
(I've heard it's difficult to vet legal email addrs with their many
diff formats.)
Seems it would cover all cases. Counterexamples welcome!
And might be tamper-proof. But what happens when the guy types "\ncc:
spam-targets\n" in the body of the email? Do I have to sanitize all of
that?
-- Pete Wilson
http://www.pwilson.net/
Alan J. Flavell
> Sorry if I'm restating the obvious.
Unfortunately, the people who are most in need of your advice aren't
reading it, otherwise they'd already have taken their spam-relays off
the air.
> I'm starting to believe that every CGI script does/can/should know up
> front to whom to send every form-submitted email, without exception.
If the transmitted mail also contains text which is provided by the
submitter, then, by allowing the submitter to specify the destination
address, you've implemented a potential spam relay.
If you're only using it to create a thank-you note, containing
standard boilerplate that isn't under control of the submtter, and
nothing more than a few _short_ strings plugged in from the submission
script, then you _might_ get away with sending it to the address
provided by the submitter.
> So perhaps it's OK, and maybe required, simply to discard all
> submitted email headers
I certainly wouldn't let the submitter control complete headers!
Allowing them to include strings (without newlines of course) to
specify an email address that will be included into a prepared
boiler-plate header is a different issue, see above.
> And might be tamper-proof. But what happens when the guy types "\ncc:
> spam-targets\n" in the body of the email?
It includes your implausible text into the body of the email. So
what? Once the headers are ended, you're in the mail body. All
further material is body content, no matter how implausible.
You might want to make some effort to defend recipients against mail
client software which is foolish enough to interpret body content by
guesswork rather than by the requirements of email standards, but
basically if it does that then that's not your fault as sender - the
responsibility for the security violation lies squarely with the
implementer of the defective client software.
begin 666 this is plain text
until the bitter
end
Alan J. Flavell
> I did a search on the archives and didn't see any mention of it here -
> has anyone found a solution to the following cgiemail spam exploit:
>
> http://msgs.securepoint.com/cgi-bin/get/bugtraq0206/113/1.html
http://msgs.securepoint.com/cgi-bin/get/bugtraq0206/113.html
is the actual report.
Gosh, and how obvious, once it has been pointed out.
> Contrary to what the article says,
Contrary to what the followup claims, anyway...
> it is NOT hard to exploit.
Well, if the only available templates on the server did not have any
user data inserts into their headers, it cannot be exploited.[1]
> lets say I have a template for a form where the users' email is set as
> the from: address of the resulting form email. i.e. the headers are:
Yes, as soon as an attacker can see that there's a template available
which is putting user-supplied data into the mail headers, they are
set. (Of course, the other features of the template might make it
unsuitable for their purposes - but the risk is certainly there.)
> If you use a %0a (newline) character in your form submission of your
> email address you could insert another line into the headers of the
> email - including Bcc:, cc: etc,
Evidently the CGIemail code _ought_ to forbid the insertion of
newline characters from user data into the header part.
Or as someone else commented on the thread, it might be sufficient to
always insert white space after a newline from user data.
> This exploit works on ANY cgiemail form where any of the form fields
> are reproduced in ANY header of the template file. i.e. if your
> subject is taken from a form field, then you are vulnerable.
I can only confirm your observations (and be astonished that it took
so long for anyone to notice this!).
cheers
[1] Even after this bug has been fixed, it seems to me that someone
should write a security note into the documentation, warning the
designers of templates against designing a template which could be
capable of exploitation as a spamming gateway. The blame for that
(once this newline bug is fixed) would not lie with CGIemail but
rather with the person implementing the template, but at least they
should be warned. IMHO, anyway.
Bruce Lewis
> I did a search on the archives and didn't see any mention of it here -
> has anyone found a solution to the following cgiemail spam exploit:
>
> http://msgs.securepoint.com/cgi-bin/get/bugtraq0206/113/1.html
>
> Contrary to what the article says, it is NOT hard to exploit.
"Hard" is always a relative term. There is another script in widespread
use that is easier to exploit, which is why you don't see reports of
cgiemail actually being exploited in this way. Even if exploited, it
would be harder for the spammers to make the message look the way they
wanted it to look.
At this point, I don't think mitigating the spamming risk is worth the
inconvenience to you. However, there are things you can do if you
really want to.
Instead of From: [email] in the headers, you could put mailto:[%U,email]
early on in the body. Most modern mail readers make this easy to reply
to.
If you have multiple possible recipients, create aliases for them:
rc...@mydomain.com, rc...@mydomain.com, etc. Then use the header:
To: rcpt[%-1.1,rcpt]@mydomain.com
This restricts the rcpt input to a length of 1, so a spammer can't use
it for arbitrary recipients.
Someday, if you're lucky, BRL will be available at your ISP so you
can have the ease of cgiemail with more power.
You would have a BRL template like this:
_______________________________________________________________________________
[(inputs email)]
<h1>Mail sent</h2>
[(mail (list "m...@mydomain.com")]
TO: m...@mydomain.com
From: [email]
Subject: this is a BRL generated email
...
[)]
<p>Thank you, [email]! Your message has been sent.</p>
_______________________________________________________________________________
With BRL, the recipient list is always (list "m...@mydomain.com") no
matter what the value of the email input is. There is tremendous power
for filtering/escaping input values if you need it, but in this case you
don't need it, as the headers do not control the recipient list.
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.codesimply.net/
"alum.mit.edu")]>
Alan J. Flavell
> "Hard" is always a relative term. There is another script in widespread
> use that is easier to exploit,
Indeed, and you don't need to tell us which one you have in mind :-}
> Even if exploited, it
> would be harder for the spammers to make the message look the way they
> wanted it to look.
That surely depends on the design of the template that they are using
with CGIemail.
But as we can learn from the modus operandi of some of the exploiters
of M***'s F*******, what they do is to inject MIME headers which
effectively make the original message invisible, and promote their own
insertion into the body as the message which will be presented to the
recipient.
Someone writing a template for CGIemail would either have to be lucky
or well-advised, if they are to avoid that happening to them.
> At this point, I don't think mitigating the spamming risk is worth the
> inconvenience to you.
Obviously, as your code is free software, the choice of what to do
with it is yours. But nevertheless, if I might make a suggestion...
Would it be _so_ hard to detect which part of the template is headers
and which part is body, and disallow the insertion of newlines from
submitted data into headers?
all the best
Bruce Lewis
> Obviously, as your code is free software, the choice of what to do
> with it is yours. But nevertheless, if I might make a suggestion...
>
> Would it be _so_ hard to detect which part of the template is headers
> and which part is body, and disallow the insertion of newlines from
> submitted data into headers?
Probably not terribly hard, but I'm behind on new releases of BRL, so my
coding effort likely won't go into improving cgiemail any time soon.
Code such as you describe could also be used to mitigate the first
security risk listed at
http://web.mit.edu/wwwdev/cgiemail/webmaster.html#security
It would be quite useful. I don't know if I'll ever be the one to code
it, though.
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.codesimply.net/
"alum.mit.edu")]>
--
Pete Wilson
> On Nov 13, Bruce Lewis inscribed on the eternal scroll:
>
> > "Hard" is always a relative term. There is another script in widespread
> > use that is easier to exploit,
>
> Indeed, and you don't need to tell us which one you have in mind :-}
Well, because I'm so like unto a newborn babe I'd like someone to tell
/me/ which one. Why the secret? Is it a FAQ? I don't see it there, but
maybe I'm missing something. What code should I avoid? I've no idea I
don't know the name of it. Thanks, Alan.
> That surely depends on the design of the template that they are using
> with CGIemail.
>
> But as we can learn from the modus operandi of some of the exploiters
> of M***'s F*******, \
And what in the world do you mean by this? One of Matt's old,
abandoned scripts? Let's hear about it so we won't use it. See, those
things are still around and, I guess, in wide use despite that Matt
has disowned, disavowed, and disinherited them totally, as I hear it.
Or maybe that's in the FAQ. My apologies if so. I haven't found it
yet. Would make a first-class FAQ if it's /not/ there, imo:
"What are the known security problems with free email scripts?"
> Would it be _so_ hard to detect which part of the template is headers
> and which part is body, and disallow the insertion of newlines from
> submitted data into headers?
No, of course not. As you well know. But my approach now will be
simply to disallow any user-supplied headers except "subject: "; and
to look hard at that one. I'm convinced that no form-invoked CGI email
needs any user-supplied recipients anyway. We're not making
generalized email interfaces and the user has no need (imo) to supply
recipients. Phooey on that! (Counterexamples always welcome!)
-- Pete Wilson
http://www.pwilson.net/
--
William Alexander Segraves
news:5e39b87d.02111...@posting.google.com...
<snip>
> No, of course not. As you well know. But my approach now will be
> simply to disallow any user-supplied headers except "subject: "; and
> to look hard at that one.
Pete, you should really test this for yourself. My tests showed I could
employ the (earlier-cited) exploit, even in the Subject: header. Right after
verifying the vulnerability, I pulled my cgiemail templates off of my
MindSpring web site, even though they would have been difficult to exploit
because of the formats of the templates, in this case, Adobe FDF.
> I'm convinced that no form-invoked CGI email
> needs any user-supplied recipients anyway. We're not making
> generalized email interfaces and the user has no need (imo) to supply
> recipients. Phooey on that! (Counterexamples always welcome!)
Counterexample: If the user wishes the cgiemail output to be mailed to
himself, the user needs to be able to supply his E-mail address as input
that would be placed in the template's To: header.
OTOH, any user with access to cgiemail would be able to hard code his return
address into the To: header of the template; so such use would not expose
the template to the aforementioned exploit.
Bill Segraves
Alan J. Flavell
> Is it a FAQ?
It's not really a CGI FAQ, since CGI FAQs are mostly about
implementing CGI solutions, not about choosing other people's
free scripts.
> I don't see it there, but
> maybe I'm missing something. What code should I avoid?
I think it's clear from your posting that you already know...
> And what in the world do you mean by this? One of Matt's old,
> abandoned scripts?
Well, if you go to this page, you might start to believe so:
http://www.scriptarchive.com/nms.html
but if you go to this one, it's less than entirely clear:
http://www.scriptarchive.com/formmail.html
But either way, there are two issues:
- old versions had significant security exposures. New versions are
claimed to have solved all known exposures. But are still written
using the original, suspect, coding style. As he now publicly
acknowledges - and all due respect to him for that.
- _any_ script, no matter how well-written in other respects, which
allows a user to freely control both the recipient address and the
mail body content is capable of being misused as a spam relay.
> > Would it be _so_ hard to detect which part of the template is headers
> > and which part is body, and disallow the insertion of newlines from
> > submitted data into headers?
>
> No, of course not. As you well know.
I'm not a professional C programmer, however, and I'm unfamiliar with
the code of CGIemail, even though I've installed it for users in the
past; so I'd be reluctant to offer to fix this myself. (I offer
Usenet quite a number of resources where I believe I can confidently
make myself useful, but I try to recognise where the limits of my
expertise lie.)
> But my approach now will be
> simply to disallow any user-supplied headers except "subject: ";
I don't think that helps. If they can smuggle-in a newline, it
doesn't matter which header they smuggle it into.
As far as I can see, you need to understand how CGIemail parses the
template, and teach it to distinguish between the body part (where
there seems to be no issue with passing newlines into the generated
mail body, and this seems to be a desirable function; and the head
part (where it should disallow all newlines generated from user
input).
cheers
Pete Wilson
> On Nov 14, Pete Wilson inscribed on the eternal scroll:
>
> > Is it a FAQ?
>
> It's not really a CGI FAQ, since CGI FAQs are mostly about
> implementing CGI solutions, not about choosing other people's
> free scripts.
Oh, Alan, for shame. Implementing a solution, in my view, includes
perhaps choosing other people's scripts. You say later in your post
that you've chosen, in the past, to install cgiemail for clients.
Would you not call that "implementing a solution?" I sure would. The
FAQ is not impressive at all. <rant> Considering: that CGI script is
so fertile a field for exploits; that there is no complete, correct
doc [1] to tell folks how to write a script; and that everybody's
writing and installing scripts no matter their aptitude or skill.
Matt, in the link you gave, says he wrote his mail script as he was
learning to code -- learning! just think of it! -- in high
school.</rant>
It seems to me the FAQ ought to address this stuff: there's a huge
need, imo. But it does not.
[1] And please don't tell me to follow the UIUC "spec" :-) That
one-pager's a joke.
Anyway, you go on to say:
> - old versions had significant security exposures.
Yep, and the old versions are still cloning all over the place, I'll
bet. I agree with you that there are better versions out there now.
But, just because the web /is/ the web, all this old junk is lying
around waiting to be picked up and used by somebody, all unaware. An
existential fact of web life.
> - _any_ script, no matter how well-written in other respects, which
> allows a user to freely control both the recipient address and the
> mail body content is capable of being misused as a spam relay.
Absolutely! But didn't I hear you say a couple of days ago that the
mail body was safe? What nightmare confluence of accident and design
occurred to you to change your mind about that? Or are we both just
retreating into the very safe corner?
----------
Quote I mentioned above just for completeness:
> ... I'm unfamiliar with
> the code of CGIemail, even though I've installed it for users in the
> past;
----------
> > But my approach now will be
> > simply to disallow any user-supplied headers except "subject: ";
>
> I don't think that helps. If they can smuggle-in a newline, it
> doesn't matter which header they smuggle it into.
My complete remark was "But my approach now will be
simply to disallow any user-supplied headers except "subject: "; and
to look hard at that one."
And now I see what Bill Segraves says:
> you should really test this for yourself. My tests showed I could
> employ the (earlier-cited) exploit, even in the Subject: header.
I tell you, if the solution is to edit out newlines, then I'm
troubled. Seems to me the history of exploits has been to use ever
more clever, astute, studied techniques. Isn't that your take, as
well? Next we'll be writing posts about how some guy was able to get
some email prog to xor two innocent strings together to come up with
"rm -r /" or something, and then somehow to persuade the shell to
execute that guy.
But, considering Bill Segraves's remarks, my approach is to accept a
message body and no more.
> As far as I can see, you need to understand how CGIemail parses the
> template, and teach it to distinguish between the body part (where
> there seems to be no issue with passing newlines into the generated
> mail body, and this seems to be a desirable function; and the head
> part (where it should disallow all newlines generated from user
> input).
Yes. Well, I'm beefing up a piece of C code. That'll serve for the
time being.
I don't like that it calls on an external mail program. But that's a
completely different issue than user-supplied newlines, as you know.
Here's a thought: Gypsy Mail completely avoids external system
programs; it constructs its own SMTP headers and sends the mail
itself. Maybe that's the way to go.
Sorry for the stream-of-consciousness reply: I'm just a ramblin' kinda
guy tonight.
-- Pete Wilson
http://www.pwilson.net/
--
Alan J. Flavell
> > - _any_ script, no matter how well-written in other respects, which
> > allows a user to freely control both the recipient address and the
> > mail body content is capable of being misused as a spam relay.
>
> Absolutely! But didn't I hear you say a couple of days ago that the
> mail body was safe?
The body, in itself, _is_ safe.
> What nightmare confluence of accident and design
> occurred to you to change your mind about that?
I didn't. It's only if they can control both the body and the
addressee(s) that this problem occurs.
Alan J. Flavell
> I tell you, if the solution is to edit out newlines, then I'm
> troubled. Seems to me the history of exploits has been to use ever
> more clever, astute, studied techniques. Isn't that your take, as
> well?
You have a point here, which I seem to have missed in my earlier
reply. The correct approach to handling user-supplied data in a
security-sensitive situation is to permit only the characters which
you know to be safe, rather than trying to exclude only those
characters which you know to be unsafe.
Randall Bart
comp.infosystems.www.authoring.cgi stood in awe as "Alan J. Flavell"
<fla...@mail.cern.ch> uttered:
>> Absolutely! But didn't I hear you say a couple of days ago that the
>> mail body was safe?
>
>The body, in itself, _is_ safe.
I've seen a situation where the body is not safe. I hope it doesn't apply
to CGIemail. (It probably doesn't.) The calling script could spoof a
delimiter record. After the delimiter, you're in the headers of another
message.
--
RB |\ © Randall Bart
aa |/ ad...@RandallBart.spam.com Bart...@att.spam.net
nr |\ Please reply without spam I LOVE YOU 1-917-715-0831
dt ||\ http://RandallBart.com/ DOT-HS-808-065 MS^7=6/28/107
a |/ Ånåheim Ångels 2002 World Chåmps!
l |\ A man's garden and his character both reflect
l |/ on the weeding done during the growing season
Alan J. Flavell
> >The body, in itself, _is_ safe.
>
> I've seen a situation where the body is not safe.
If you forgot to invoke sendmail with the -oi option, right?
> I hope it doesn't apply to CGIemail.
The source is available for inspection. I'd suppose the spammers have
already taken a careful look.[1]
This:
strcat(strcpy(command, PATH_SENDMAIL), " -oi -t");
seems to be the key line in the code.
> The calling script could spoof a delimiter record.
In _this_ context, sendmail doesn't have any "delimiter record".
If you want to do a security walkthrough of the code, I think you'd
get better results by reading it, rather than hypothesizing on the
basis of what other folks might have got wrong.
ttfn
[1] Although I've already admitted to surprise that they haven't
exploited this header newline vulnerability. Perhaps BRL was right,
that the rich pickings of That Other Form Mailer were just too easy
for them to bother with cgiemail.
William Alexander Segraves
news:5e39b87d.02111...@posting.google.com...
<snip>
> message body and no more.
EarthLink makes this clear in their advice, i.e., all the elements of the
header section should be hard-coded.
Bill Segraves
Pete Wilson
> The correct approach to handling user-supplied data in a
> security-sensitive situation is to permit only the characters which
> you know to be safe, rather than trying to exclude only those
> characters which you know to be unsafe.
OK, right. Then, earlier, Randall Bart wrote:
> I've seen a situation where the body is not safe. I hope it doesn't apply
> to CGIemail. (It probably doesn't.) The calling script could spoof a
> delimiter record. After the delimiter, you're in the headers of another
> message.
Heh! Wow! Thanks for that heads-up, Randall. I need something to read
anyway: I'll go get Mitnick's book.
-- Pete Wilson
http://www.pwilson.net/
a |/ Ånåheim Ångels 2002 World Chåmps!
BoSox next year! Yeah, suuuuure.
Jacqui caren
> On Nov 15, Randall Bart inscribed on the eternal scroll:
>
>> >The body, in itself, _is_ safe.
>>
>> I've seen a situation where the body is not safe.
>
> If you forgot to invoke sendmail with the -oi option, right?
>
>> I hope it doesn't apply to CGIemail.
>
> The source is available for inspection. I'd suppose the spammers have
> already taken a careful look.[1]
>
> This:
>
> strcat(strcpy(command, PATH_SENDMAIL), " -oi -t");
>
> seems to be the key line in the code.
>
>> The calling script could spoof a delimiter record.
>
> In _this_ context, sendmail doesn't have any "delimiter record".
>
If you have a tatty SMTP library and you send the body verbatim
you could end up sending a body with a '.' in the middle
on a ling of its own.
The rest of the body could then be considered by the SMTP server
as a sequence of commands.
Of course nobody is that stupid to actually thnk they can
write thier own SMTP libraries without knowing this sort of
thing. At least I would hope that this is true.
Thank god for perl we have Graham Barr the "Net:: god" :-)
Jacqui