Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Web :: Apps :: web5031.htm

FormMail anonymous mail forwarding
25th Jan 2002 [SBWID-5031]

	FormMail anonymous mail forwarding


	FormMail 1.9


	From Ronald F. Guilmette  <>  &  Infinite  Monkeys
	&  Co.  Justin  Mason   <>   -   maintainer   of
	SpamAssassin                                                  whitepaper] :

	This advisory describes various methods and mechanisms  for  the  remote
	abuse of the widely-used FormMail script, version 1.9, to send  arbitrary
	e-mail messages to arbitrary recipients  without  the  consent  of,  and
	against the wishes and intentions of those who have  installed  the  script
	on their web servers. Essentially all of the exploits  described  herein
	are also applicable to  ear- lier (pre-1.9) versions of FormMail.

	General information on the widely-used free FormMail CGI script  may  be
	found at the following URL:





	By manipulating inputs to the FormMail CGI script, remote users  may  abuse
	the functionality provided by FormMail to cause the local mail server  on
	the same (web) server system to send arbi- trary e-mail messages  to  arbitrary
	e-mail destination addresses. Such e-mail messages may contain  real  or
	forged sender e-mail  addresses  (in  the  From:  headers)  entirely  of
	the attacker\'s choosing. In some cases, the envelope  sender  addresses
	of  such messages may also be set to arbitrary values by the attacker.

	When and if the vulnerabilities described below do exist (which is  dependent,
	in some cases, upon script installation configura- tion choices  and  web
	server  configuration  choices)  and  when  and  if  they  are  in  fact
	exploited by an outside attacker,  message  recipients  will  have  only
	incomplete e-mail tracing information available in  the  message  e-mail
	headers. This incomplete tracing information  will  lead  back  only  as
	far as the web server that hosts the FormMail  script.  The  IP  address
	actually used to ini- tiate the messages will not  be  available  to  these
	recipients. The originating IP address of the attacker may  or  may  not
	be available (in local web server logs)  to  the  administrator  of  the
	exploited web server, depending on local web server logging, log file  retention
	policies, and the length of time that elapses between  exploitation  and
	the time the local administrator becomes aware of the  exploitation.  (Of
	course, even in cases where  web  server  logs  are  available,  tracing
	information contained therein may perhaps allow  tracing  of  the  attacker
	only as far back as whatever anonymizing HTTP proxy the attacker used.)




	We have followed the notification guidelines laid out in:


	with respect to this advisory.  Both  authors  of  the  present  advisory
	attempted to contact the FormMail maintainer via  the  e-  mail  address
	given on the FormMail home  page  more  than  five  working  days  prior
	to publication of this advisory. No response  from  the  maintainer  was
	forthcoming. Attempt were also made to contact the maintainer  via  telephone
	but were unsuccessful.




	The FormMail script has a  long  and  unenviable  history  with  regards
	to security issues. Originally intended as a  helpful  free  CGI  script,
	usable in the construction of simple interactive `contact us\' type  web
	forms, it was  originally  created  and  distributed  July  9,  1995  and
	subsequently underwent several  revisions  culminating  in  version  1.6
	which was released May 2, 1997. The  1.6  version  became  widely  used,
	and copies of the 1.6 version are still installed  and  publicly  accessible
	in  many locations at the present time.

	Sometime between the release of the 1.6 version of FormMail  and  March,
	2001, various Internet users became aware that  spammers  were  exploiting
	the relatively modest and weak security checks within  the  1.6  version
	to send large quantities of  unsolicited  `spam\'  e-mail  to  large  numbers
	of recipients via exploited FormMail scripts. In effect,  spammers  were
	using  the  exploited  FormMail  scripts  in  ways  that  rendered  them
	functionally  equivalent  to  anonymizing  open  e-mail  relay  servers.
	Eventually,  someone  filed  a  public  security  advisory  regarding  these
	exploitations and the now evident security  problems  with  the  FormMail
	script.[1] Later reports indicated a  belief  that  spammers  were  actively
	searching the net for exploitable FormMail scripts.[2] At least two  different
	parties have apparently been motivated (by FormMail\'s evident  security
	problems) to create and  distribute  their  own  independently-developed
	versions of FormMail which allegedly close the security loopholes.[3]

	Subsequent to the release of the 1.6 version of the script, 1.7  and  1.8
	versions were also released.  On  his  web  site,  the  FormMail  author
	himself  notes  that  these  versions  have  unspecified   (and   perhaps
	different; see footnotes) security vulnerabilities, and that  all  users
	should upgrade to version 1.9 ``IMMEDIATELY\'\'.

	Version 1.9 of FormMail was released by its author on  or  about  August
	3, 2001, according to the comments  in  the  script.  This  version  has
	been alleged to rectify the various  previously  identified  security  issues
	with FormMail, including its prior ability to  be  manipulated  into  behaving
	like an anonymizing open mail relay.[4]


	Pre-1.9 Exploitation


	Exploitation of FormMail versions prior to 1.9  for  the  forwarding  of
	e-mail messages which have been effectively anonymized[5]  was  rendered
	trivial by the script\'s total reliance on  information  transmitted  by
	the web client to the web server (and hence to the FormMail CGI  script)
	for both authentication of the request and  for  specification  of  recipient
	e-mail  address(es)  for  each message.

	FormMail\'s authentication of incoming requests, such  as  it  was  (and
	is, in version 1.9), is limited to the following  rather  rudimentary  check
	on the HTTP_REFERER environment variable passed to the script  from  the
	local web server. (The web server, in its turn, obtains this value  from
	the Referer: HTTP  header  supplied by the HTTP client.)


	if ($ENV{\'HTTP_REFERER\'}) {

	    foreach $referer (@referers) {

	        if ($ENV{\'HTTP_REFERER\'} =~ m|https?://([^/]*)$referer|i) {

	            $check_referer = 1;





	else {

	    $check_referer = 1;




	Note that further up in the script, the  original  script  installer  is
	required to have defined the @referers  array  to  a  list  of  strings,
	each of which is supposed to be a domain name or  IP  address.  These  domain
	names and/or IP addresses are, by  their  inclusion  in  the  installer-supplied
	definition of @referers, effectively authorized to run web servers  that
	will serve up HTML pages containing HTML forms that  may  work  with  this
	specific locally-installed copy of FormMail.  So,  for  example,  if  the
	local FormMail installer had wanted to limit the script\'s usage so  that
	it could only be  used  in  conjunction  with  HTML  forms  resident  on
	the web servers  known  as  and  then
	the installer would have previous defined the @referers array as  follows:

	     @referers = (\"\", \"\");


	There exist several ways to easily bypass  and  circumvent  the  HTTP_REFERER
	checking code shown above. The most obvious way,  and  the  way  that  most
	attackers will certainly  use  is  simply  to  decline  to  provide  any
	Referer: header at all as part of the HTTP request. In such  cases,  the
	attacker  will  effectively  ``pass\'\'  the   HTTP_REFERER   validation
	test[6], and the remainder of the FormMail script will  then  be  executed.

	Even though it is clear that  the  simplest  and  easiest  way  to  cir-
	cumvent the HTTP_REFERER check in FormMail is simply  to  avoid  including
	any Referer: header in the HTTP request, for the  sake  of  completeness
	we would also like to note some other methods whereby  this  same  check
	could be circumvented even in programming contexts[7] where omission  of
	Referer: headers may  be  difficult or impossible to achieve.

	Specifically, it should  be  noted  that  the  Perl  regular  expression
	matching attempt:

	     $ENV{\'HTTP_REFERER\'} =~ m|https?://([^/]*)$referer|i


	is not left-anchored prior to the https?: scheme  specification  nor  is
	it right-anchored after the $referer domain name.

	The lack of left-anchoring prior to the https?: scheme  specifica-  tion
	portion of the regular  expression  allows  an  attacker  to  ``pass\'\'
	this  simple-minded  HTTP_REFERER  validation  test  as  long   as   the
	HTTP_REFERER value (set from the HTTP Referer: header) is some  URL  containing
	a match for the regular expression anywhere within its entire length.

	An attacker may easily exploit this lack  of  left-anchoring  by  simply
	loading, and then submitting an HTML form to the  desired  FormMail  CGI
	from the attacker\'s own local web server using a  extended  `spoof\'  URL
	which contains a substring matching the reg- ular  expression  somewhere
	within the entire URL string.  The  matching  substring  may  be  presented
	as part of the right context  of  the  complete  URL,  and  specifically
	within a portion of the URL that will, by convention, be  ignored  by  many/most
	web servers when loading a page corresponding  to  the  given  URL.  For
	example, the following URL:



	if included as the URL in an HTTP  GET  request  will  typically  result
	in the HTTP client receiving a copy of the same web page that would  have
	been obtained if the requested URL had been just:



	because a typical web server will simply ignore the trailing  por-  tion
	of the URL past the question mark.[8] Typical HTTP clients on the  other
	hand, if asked to perform such a GET operation, will do so (with  the  help
	of the relevant web server) but will then preserve the  entire  original
	request URL and will later present that  as  the  Referer:  value,  when
	and if some HTML form on the page is the subject of a submit operation.

	The HTTP client\'s preservation of the entire URL, including the  trailing
	`spoof\' substring, allows most typical HTTP clients to  trivially  pass
	FormMail\'s simple-minded HTTP_REFERER validation test even if the  attacker
	has neither built nor obtained any HTTP client software that allows  for
	suppression of Referer: head- ers[9], and even if he is writing  his  own
	attack software in some language (e.g. Javascript) that otherwise  makes
	the implementa- tion of  attacks  on  web  CGIs  particularly  easy  and

	The lack of right-anchoring after the $referer portion  of  the  regular
	expression may also be exploited by an  attacker  wishing  to  create  a
	modified FormMail HTML submission form on a web server of his  own  choosing.
	This may be more  difficult  than  exploiting  the  lack  of  left-anchoring
	however, and may perhaps  only  be  achievable  with  the  aid  of  some
	cooperative DNS server. Given the availability of such a server  however,
	a DNS `A\' record could easily be defined for an fully-qualified  domain
	name  such as:


	and that `A\' record could be defined with an IP address of  the  attacker\'s
	choosing. In this case, the  attacker  could  easily  load  his  malevolent
	locally-installed HTML exploit form (which has its  ACTION=  clause  set
	to point to the victim\'s FormMail) into his browser via a  URL  such  as:


	The attacker could then simply submit the  form  and  it  would  `pass\'
	the simple FormMail HTTP_REFERER validation check.

	Note  that  all  three  methods  for  circumventing  FormMail\'s  HTTP_REFERER
	validation remain present in the current (1.9) ver- sion of the  script,
	i.e. (1) complete  omission/suppression  of  Referer:  headers  and  (2)
	exploitation of the lack of right- anchoring and (3) exploitation of  the
	lack of left-anchoring.

	Once  an  attacker  has  passed  the   easily   circumventable   HTTP_REFERER
	validation check, he then has a mostly free  hand  to  manipulate  other
	CGI (form input) variables in order to direct an e-mail message  of  his
	choice to some selected destination address or addresses.

	FormMail  obtains  the  desired  destination  e-mail  address  for  each
	transmitted e-mail message  from  the  HTTP  client.  The  HTTP  client,
	in turn, is expected to obtain it from the pre-defined  value  of  a  hidden
	HTML form field (recipient) within a form  (or  forms)  associated  with
	the specific web site/server where  a  given  instance  of  FormMail  is
	installed. Obviously however, if (as we have seen above) it  is  trivial
	to trick FormMail into believing that  some  attacker-created  form  which
	actually resides  on  some  arbitrary  web  server  of  the  attacker\'s
	choosing is a valid ref-  erer,  then  attackers  can  certainly  manufacture
	(or simulate) forms with the recipient form field set to  any  e-mail  address

	These are the conditions which led to earlier reports of FormMail  being
	exploited, generally by bulk e-mail spammers, as if it were  a  kind  of
	anonymizing open e-mail relay server. The fundamental problem  was  that
	the HTTP_REFERER checking could be  easily  spoofed,  and  that  the  pre-1.9
	versions of FormMail performed no validation checking  of  any  kind  on
	the recipient CGI parameter. Attackers were thus allowed to set  this  parameter
	to any desired value.

	Version 1.9 of FormMail incorporated changes whose purpose was to  allow
	the actual destination e-mail addresses (i.e. the value  given  for  the
	recipient CGI parameter) for any submitted message to  be  restricted  by
	checkingthem against  an  installer-supplied  list  of  ``acceptable\'\'
	recipient e-mail addresses and/or recipi- ent domains. As noted below  however,
	these changes did not fully achieve their goal. That  unfortunate  fact,
	together with the multiple flaws in HTTP_REFERER checking  (all  of  which
	are still present in the 1.9 version) imply that even  the  current  1.9
	ver- sion of FormMail can still be used and abused for spamming, for  e-mail
	harassment, or other  purposes  neither  condoned  or  intended  by  the
	FormMail installer.


	Anonymous Mail Forwarding Exploits in FormMail 1.9


	As noted above, versions  of  FormMail  up  to  and  including  1.8  are
	believed to be vulnerable to various security  exploits,  including  but
	not limited to creative generation of  HTTP  header  and  message  data,
	leading to an installed FormMail CGI script at a targeted site  behaving
	like  an  anonymizing  open  e-mail  relay.  At  present,  spammers  are
	continuing and increasing their abuse of  such  ear-  lier  versions  of
	FormMail, especially the widely deployed 1.6 version, at  various  sites
	where these earlier versions are,  unfortunately,  still  installed.[10]

	This advisory describes various vulnerabilities in version  1.9  of  the
	FormMail script that may also lead to misuse and abuse of the script  by
	remote attackers to achieve an effect functionally equivalent to  an  anonymizing
	open e-mail relay server.

	Note that many, if not most of these exploits were also present in  versions
	of FormMail prior to the 1.9 version, and thus it  may  be  fairly  said
	that the exploits described herein are not in any sense new to  the  1.9
	version. For the sake of brevity however, we report  these  problems  as
	vulnerabilities in the 1.9 version.

	The vulnerabilities described herein may be broadly  separated  into  the
	following   categories:   (1)   creative   recipient   addressing,   (2)
	exploitation of the email and realname CGI parameters, (3)  other  regular
	expression  matching  issues,  and  (4)  mail-bombing  by  proxy   using
	FormMail. These vulnerability categories are each  described  in  separate
	sections below.


	Creative Recipient Addressing


	The preceding section noted that FormMail 1.9 suffers from the  same  HTTP_REFERER
	validation flaws as earlier versions of the  script,  thus  forcing  the
	prevention of unauthorized use/misuse of the script to rely entirely  on
	the code added in 1.9 which  attempts  to  validate  client-supplied  recipient
	e-mail addresses. These added checks contain a number of subtle and  not-so-subtle
	flaws however, any one of which, if exploited, renders  the  check-  ing
	code useless and ineffective.

	Briefly, the  recipient  address  checking  code  added  in  1.9  merely
	attempts to ensure that each comma-separated substring  of  the  client-specified
	recipient string matches (with right-anchoring only, and without case  sensitivity)
	one of a set of strings spec- ified  by  the  person  who  installs  the
	FormMail script. The array called @recipients is used to hold these  (valid
	recipient address or domain) strings and each  comma-delimited  substring
	of the client-supplied recipient CGI parameter string is checked to  see
	that it matches  (right-anchored)  at  least  one  of  these  installer-
	specified ``approved\'\' recipient address or domain strings.

	As long as this check `passes\', for any  given  comma-separated  substring
	of the recipient value, that substring will be saved in yet another  array
	(@send_to), and later on, all elements of the  ``validated\'\'  @send_to
	array are join\'d back together, with comma separators, and  the  resulting
	string replaces the old, unvali- dated recipient  CGI  parameter  value.
	That value is then later used (when writing  e-mail  headers  to  the  local
	mail server) in the following Perl statement:

	     print MAIL \"To: $Config{\'recipient\'}\\n\";


	So, for example, if the installer of the script had provided  a  definition
	of @recipients like:

	     @recipients = (\'pres\\@elsewhere.tld\', \'ourdomain.tld\');


	then all of the following client-supplied recipient addresses, if  given
	by the HTTP client, either alone or as elements of  a  comma-  separated
	list of recipient addresses, would ``match\'\' some  ele-  ment  of  the
	@recipients array definition shown above, and would thus be  allowed  as
	valid recipient addresses:


	     PRES@elsewhere.tld (See note #1)

	     vice-pres@elsewhere.tld  (See note #2)



	     user%somewhere.tld@ourdomain.tld  (See note #3)

	     user@somewhere.tld(ourdomain.tld  (See note #4)

	     user@somewhere.tld(pres@elsewhere.tld  (See notes #2, #4)

	     <user@somewhere.tld>ourdomain.tld (See note #5)

	     <user@somewhere.tld>user@ourdomain.tld (See note #6)

	     <user@somewhere.tld>pres@elsewhere.tld (See notes #2, #6)


	Unfortunately, some of the  ``acceptable\'\'  strings  shown  above,  if
	crafted by an attacker and then used within a spoofed/fraudulent HTTP  request
	may lead to undesirable  consequences,  i.e.  the  for-  warding  of  an
	associated e-mail message  to  some  recipient  (or  recipients)  having
	e-mail addresses that the installer never intended to allow  as  FormMail
	message recipients.

	Several notes regarding the example strings shown above  are  in  order:


	  1.  Comparison  of each comma-separated sub-part of the client-

	      supplied recipient string is performed without case  sensi-

	      tivity.   On systems where the initial (user ID) portion of

	      e-mail addresses is  considered  case-sensitive,  this  may

	      allow  misuse  of FormMail to send e-mail messages to unin-

	      tended recipients having e-mail addresses with  alternative

	      case  on  the same system.  Worse however, this possibility

	      opens up a hole that might perhaps allow a remote  attacker

	      to misuse an installed FormMail script in a way that avoids

	      immediate detection by any local user or administrator.  We

	      will return to this point below.


	  2.  In  fairness  to  the FormMail author, the README file sup-

	      plied with FormMail version  1.9  explicitly  and  strongly

	      suggests  that installers should prefix any and all full e-

	      mail addresses they include within the  definition  of  the

	      @recipients  array with the up-caret (^) character, thereby

	      causing subsequent regular expression  matching  for  those

	      strings  to  be anchored both on the left and on the right.

	      Following that suggestion  would  certainly  eliminate  the

	      potential  exploits  noted  above  that refer to this note.

	      Anyone following the FormMail author\'s advice  with  regard

	      to  1.9  installation  would have written their @recipients

	      definition as follows:


	      @recipients = (\'^pres\\@elsewhere.tld\', \'ourdomain.tld\');


	      rather than the way it  was  written  further  above,  thus

	      eliminating  such  obvious potential problems as being able

	      to trick FormMail into sending unauthorized e-mail messages

	      to  vice-pres@elsewhere.tld.  As we have already noted how-

	      ever, even when each and every element  of  the  installer-

	      defined  @recipients  array is set to a full e-mail address

	      (as opposed to merely a domain name) and even when each  of

	      the  e-mail  addresses  in  question  is left-anchored, the

	      check for correspondence between client-supplied  recipient

	      addresses  and the installer-defined set of allowed recipi-

	      ent addresses is performed in a  case  insensitive  manner.

	      We will return to this issue below.


	  3.  Although  the  recipient  parameter provided to FormMail by

	      the HTTP client will  have  newlines  and  carriage  return

	      characters,  if  present, removed by FormMail, and although

	      the recipients string is separated into a set of comma-sep-

	      arated  substrings  before the recipient address validation

	      occurs, no other validation of the form, format, or  syntax

	      of  the  recipient  address(es)  is performed.  This leaves

	      open the possibility of  using  the  old  and  widely-known

	      Sendmail  percent  hack[11]  form  of e-mail addressing, at

	      least in cases where one or more of  the  elements  of  the

	      @recipients array are just domain names, as opposed to full

	      e-mail addresses.


	      To understand fully why use of the percent hack  is  almost

	      guaranteed to work in such cases, one must understand that:


	         o FormMail is  designed  to  work  in  conjunction  with

	           either  Sendmail or with some work-alike program, such

	           as Postfix, and we may thus assume that whatever  mail

	           server  FormMail is hooked up to will almost certainly

	           be one that does support  the  percent  hack  form  of



	         o In  normal  (non-exploit)  operation,  the mail server

	           resident on the  same  host  as  the  FormMail  script

	           itself  will  (unless  the  administrator  has botched

	           either his Sendmail configuration or his FormMail con-

	           figuration)  accept  all  ``locally generated\'\' e-mail

	           messages  coming  out  of  the  FormMail  script   and

	           addressed  to any e-mail address whose @domain part is

	           the same as of any one of the domains  listed  in  the

	           @recipients  array.   Thus, in the preceding examples,

	           we can usually be sure that the local mail  server  on

	           the FormMail host will not disallow or reject any such

	           ``locally-generated\'\' e-mail message that is addressed

	           to  user%somewhere.tld@ourdomain.tld  because  it will

	           see  that  the  domain  portion  of  this  address  is

	           ourdomain.tld.   That alone will probably be enough to

	           satisfy Sendmail that it should accept (and, if neces-

	           sary,  forward) the mail message in question.  Also, a

	           typical Sendmail installation, even a modern one, will

	           usually not itself object to any kind of forwarding of

	           any ``locally-generated\'\' e-mail message to any  other

	           domain  or site, because it is typical to assume (when

	           configuring Sendmail) that ``local\'\'  e-mail  origina-

	           tors  can  be fully trusted, at least to send outgoing

	           e-mail to other sites.  (Note that FormMail is  acting

	           in  the  role  of a ``local\'\' and trusted user in this

	           case.)  So an attacker really only needs to  get  past

	           FormMail\'s  check  on  HTTP_REFERER (which, as we have

	           seen, is trivial to do) and then, if he can  also  get

	           past  FormMail\'s  check  of the right-most part of the

	           recipient  address  string(s)  against  the  @referers

	           array  he  will  be  able  to  send e-mail messages to

	           essentially any e-mail address anywhere on the  Inter-

	           net.   As illustrated by the example above, use of the

	           percent hack form  of  e-mail  addressing  allows  the

	           attacker to get past the latter check.


	  4.  RFC 2822, like RFC 822 before it, specifies that within the

	      text of so-called structured mail headers (e.g.   To:)  any

	      string  enclosed within matching left and right parenthesis

	      shall be taken as being  purely  commentary  material,  and

	      shall  be ignored.  Thus, if an attacker provides a recipi-

	      ent string of the form:




	      and if that  string  passes  the  (right-anchored)  regular

	      expression  matching check (i.e. matching at least one ele-

	      ment of the @recipients array),  then  a  To:  header  line



	           To: user@somewhere.tld(ourdomain.tld


	      will  be  generated by FormMail and passed to Sendmail.  In

	      such a case, Sendmail should take  everything  between  the

	      left parenthesis and the corresponding right parenthesis as

	      a comment, thus leaving it with only the user@somewhere.tld

	      address to act on.  However in this case, there is no clos-

	      ing right parenthesis before the end of the header line, so

	      this would appear to be a case where the actual behavior of

	      the mail server cannot be predicted.  In practice  however,

	      both  Sendmail  and Postfix helpfully and implicitly supply

	      the missing closing right parenthesis themselves, with  the

	      result  being  that  the  (ourdomain.tld portion of the To:

	      header   is   in   fact   ignored,   leaving    only    the

	      user@somewhere.tld part to define the actual e-mail recipi-

	      ent address.


	  5.  For a client-supplied recipient string of the form:




	      Sendmail will subsequently be fed  the  corresponding  mail



	           To: <user@somewhere.tld>ourdomain.tld


	      and  when  such a header is supplied to Sendmail along with

	      Sendmail\'s -t  (take  recipient  address(es)  from  message

	      headers) option, reports indicate that Sendmail will send a

	      copy of the message to user@somewhere.tld, and that it will

	      then ignore the remainder of the header line, i.e. the part

	      past the right (closing) angle bracket.  (This is  in  fact

	      entirely consistent with what the mail header parsing rules

	      contained in RFC 822 and 2822 would indicate  should  actu-

	      ally happen in such a case.)


	  6.  For a client supplied recipient string of the form:




	      it  would appear clear that if ourdomain.tld is included in

	      @recipients, then such a string will pass FormMail\'s recip-

	      ient  address acceptability check, and later, when Sendmail

	      is fed:


	           To: <user@somewhere.tld>user@ourdomain.tld


	      then Sendmail will most certainly send a copy of the  asso-

	      ciated    e-mail    message    at   the   very   least   to

	      user@somewhere.tld,     but      possibly      also      to

	      user@ourdomain.tld.   Reports suggest however that Sendmail

	      will ``parse out\'\' the latter e-mail address and  send  the

	      message only to the former address.  Even if the local mail

	      server used on a given victim server is one taht will parse

	      the  header  shown  above  and  then  send  to  both e-mail

	      addresses, an attacker could potentially choose some infre-

	      quently-  or  never-monitored  e-mail  address (such as the

	      traditional nobody user ID) within the targeted domain  and

	      use  that  e-mail  address to provide the right context for

	      his (spoof) recipient string.  That also will allow him  to

	      get past FormMail\'s recipient address acceptability checks.



	Exploitation of email and realname CGI Parameters


	As noted in the preceding section, clever manipulation  of  the  recipient
	CGI parameter when invoking  FormMail  1.9  can  allow  an  attacker  to
	bypass the recipient address checks imposed by  the  installer\'s  definition
	of the @recipients array, at least in cases where the installer  has  failed
	to define elements of this array  to  complete  e-mail  addresses  (i.e.
	when one or more ele- ments of the array is  just  a  domain  name)  and
	when and if the installer has failed to  left-anchor  (with  `^\')  each
	full e-mail address within the @recipients array definition. Even  in  cases
	where all elements of the @recipients  array  are  full  e-mail  addresses
	and where these are all left-anchored, an attacker may perhaps  still  be
	able to bypass FormMail\'s recipient address checks by exploiting  various
	weaknesses in FormMail\'s regular expression matching code, as  we  will
	show in the next section.

	Clever bypassing of the checks applied to  the  comma-separated  substrings
	of the recipient CGI parameter may however not even be necessary so  long
	as the attacker is willing to supply  cleverly  constructed  values  for
	the email and/or realname CGI parameters, and so long  as  the  attacker
	is willing to allow one copy  of  his  e-mail  message  to  go  to  some
	``permitted\'\'  recipient  address,   in   addition   to   some   other
	attacker-specified list of addresses.

	The email and realname CGI parameters  may  undergo  even  less  scrutiny
	by  FormMail  than  the   comma-separated   recipient   substrings.   In
	fact the email and realname CGI parameters  may  undergo  no  validation
	whatsoever. (The realname parameter  most  certainly  does  not  undergo
	any validation whatsoever within FormMail, and the email parameter  will
	not undergo any validation as long as it is not listed as a  required  field
	in the list of required form fields that is itself initialized from  the
	client- supplied value of yet another hidden form field. Given  that  an
	attacker, either a determined one or a hurried and careless one, will  most
	probably set the value of the required hidden form field to null  or  no
	value, we will just  simplify  the  remainder  of  our  presentation  by
	assuming, from here forward, that neither the email  CGI  parameter  nor
	the realname CGI  parameter  undergo  any validation.)

	One critical additional point to note here is that neither the  email  CGI
	parameter value nor the realname CGI parameter value are in any  way  ``cleaned
	up\'\' by FormMail before they are printed to the local mail server.  Specifically,
	the values of these variable do not have carriage  returns  or  newlines
	removed before they are given to the mail server.

	Once they have been supplied by the HTTP client, both the email and  realname
	CGI parameter values are printed, verbatim and with- out  filtering,  to
	the local mail server via  the  following  Perl statement:

	     print MAIL \"From: $Config{\'email\'} ($Config{\'realname\'})\\n\";


	One\'s first thought upon seeing this statement is that the lack  of  filtering
	or validation applied to the email and realname  CGI  parameters  cannot
	possibly be harmful, given the benign  context  (i.e.  a  From:  header)
	within which these values will appear. That thought would be  misleading
	however, because of the lack of  newline  removal  for  these  parameter

	Because an attacker can embed newlines in either or both  of  these  CGI
	variable values, he can also effectively change  the  context  in  which
	the remaining (rightward) characters of either value appear to the  local
	mail server. Specifically, an attacker could set the value of the  email
	parameter to some string such as:

	     IGNORED\\nCc: user@somewhere.tld,...


	where \\n represents a  newline  character.  This  rather  simple  trick
	provides the attacker with access to a self-generated Cc:, Bcc:,  or  (secondary)
	To: header context which, once achieved, provides the attacker  with  an
	avenue to direct the local mail server  to  send  the  attached  message
	to some arbitrary set of e- mail  addresses,  in  addition  to  whatever
	address may have been specified (via the recipient  CGI  parameter)  for
	inclusion in the earlier To: header.

	As should be apparent from the Perl print statement shown above, this  same
	context shift (achievable via embedded newlines) may  also  and  equally
	be exploited via clever construction of a suit-  able  attacker-supplied
	value for  the  realname  CGI  parameter.  In  this  case  however,  the
	attacker would need to take care to also  escape  from  the  confines  of
	the paired parentheses that  the  script  will  supply  to  enclose  the
	realname value. Given that the  realname  parameter  value  will  appear
	in  the  mail  headers  sur-  rounded  by  a  pair  of  open  and  close
	parenthesis, the ``smuggling in\'\'  of  additional  recipient  addresses
	via the realname CGI parameter requires the  attacker  to  include  some
	strategically- placed parenthesis of his own in the value he  passes  to
	the vic- tim web server for the  realname  parameter.  For  example,  the

	     IGNORED)\\nCc: user@somewhere.tld\\nX-Ignore: (


	could be supplied by an attacker as the realname  CGI  parameter  value,
	thus closing  the  already-opened  SMTP  header  comment,  escaping  to,
	and creating a new (Cc:) e-mail header context  (which  is  then  filled
	with victim e-mail addresses), escaping again to another  new  e-mail  header
	context, and then finally sup- plying a open parenthesis  to  match  the
	closing one that will be supplied by the Perl print statement within  FormMail.

	Last but by no means least, it should be noted that  vulnerable  FormMail
	installations may be less than ideal as a vehicles for  distributing  e-mail
	messages, either unsolicited or otherwise,  due  to  FormMail\'s  rather
	inconvenient (for the spammers) habit of appending its own  unique  legend
	just ahead of the body text of any given  mail  message  that  it  forwards.
	FormMail always prepends a set of body text lines  having  the  following
	general form to each e-mail message it passes to the local mail server:

	  Below is the result of your feedback form.  It was submitted by

	  (sender address) on date/time stamp



	This additional leading  body  text  would  appear  to  be  annoying  to
	spammers who would much prefer to have the text of their own mes-  sages
	appear at the very start of the  message  body  text.  (We  assume  that
	this spammer-annoying aspect of FormMail is one of the reasons,  if  not
	the primary reason that spammers have gener-  ally  shown  a  preference
	for using open mail relays, as opposed to  open  FormMail  scripts,  for
	sending their messages.)

	Unfortunately however, given that the email  and  realname  CGI  parameters
	of FormMail may contain embedded newlines, it  is  apparent  that  either
	of these parameters may be set, by an  attacker,  to  a  value  which  includes
	not only  additional  recipient  addresses,  but  also  additional  mail
	headers and additional ini- tial message body text  of  the  attacker\'s
	choosing.  For example, the email parameter could be set to:

	     \\nCc: user@somewhere.tld\\nSubject: $$$\\n\\nMAKE MONEY FAST!!!


	thus causing the text \"MAKE MONEY  FAST!!!\"  to  appear  in  the  out-
	going message as the very  first  line  of  the  message\'s  body  text.
	Furthermore, a value such as the one shown just above could  be  followed
	by arbitrarily many additional newline characters, thus pushing  the  FormMail
	supplied legend text far down below the attacker\'s desired subject  header
	and initial message text (and perhaps even entirely off  the  `front  page\'
	of what the messages recipient will see  when  he  first  looks  at  the
	received  message).

	This tactic may of course  be  applied  with  essentially  equal  effect
	to either the email or realname parameters, except that the  caveats  mentioned
	above concerning the balancing of parenthe- sis would apply in the  case
	of  manipulation  of  the  realname parameter.

	These possible tactics for ``hiding\'\'  the  otherwise  spammer-  annoying
	FormMail leading body text are not, unfortunately, the only  ones  possible.
	As  one  careful  early  reviewer  of  this  advi-   sory   noted,   the
	vulnerability which allows an attacker to include newlines in  the  email
	an/or realname CGI parameters might also open up an avenue  whereby  the
	FormMail-supplied leading body text could be  effectively  removed  from
	the view of a message recipient via the  careful  construction  of  MIME
	e-mail headers which achieve that  exact  effect.  (This  design  of  an
	exploit making use of this approach is  left  as  an  exercise  for  the


	Other Regular Expression Matching Issues

	We have noted above several ways of bypassing  FormMail\'s  attempts  to
	validate a client-supplied recipient string, where most of  these  methods
	rely on various obscure  and  not  widely  known  aspects  of  e-mail  address
	parsing rules. These are by no means the only ways to  circumvent  these
	recipient address validation checks however. These  checks  may  also  be
	bypassed via at least three different exploits relating  to  FormMail\'s
	use of regular expressions for e-mail  address  matching/validation.  These
	addi- tional exploit techniques are described below.

	The first regular  expression  exploit  we  present  offers  an  attacker
	an easy opportunity to get past FormMail\'s recipient  address  checking
	tests, although perhaps in a  way  that  will  be  quickly  detected  by
	an alert local administrator (of the  exploited  server).  Note  that  due
	to the flow-of-control logic used  within  FormMail,  an  attacker  must
	get past these tests at least once, or else no e-mail messages  will  be
	sent at all.

	Consider the case  where  the  local  FormMail  installer  provided  the
	following definition for the @recipients array:

	     @recipients = (\"^john\\@our-server.tld\");


	Given that the string enclosed within the double  quotation  marks  will
	in fact be used,  verbatim,  as  a  regular  expression  within  a  Perl
	regular  expression  match,  and  given   that   within   such   regular
	expressions,  each  period  character  actually  stands  for  a  single-
	character wild card character, an attacker could supply a value for  the
	recipient CGI parameter such as:



	In such a case, unless by some extremely remote  chance,  there  happens
	to be another server on the same  local  network  whose  non-  qualified
	node name is our-serverXtld, the mail message sent by the  attacker  through
	FormMail to the specified recipient address (and perhaps  also  to  some
	additional set of recipient addresses smuggled in  via  the  email  and/or
	realname CGI parameters) will almost certainly generate a  undeliverable
	bounce message for the non-existent john@our-serverXtld  address.  Where
	will this bounce message go?

	We would hope that the undeliverable bounce  message  would  be  directed
	to some responsible local administrator who would then  quickly  realize
	that the game is afoot, and that somebody some-  where  is  presently  attempting
	to exploit the locally-installed copy of FormMail, but in point of  fact
	this is unlikely to occur.

	What is clear is the the bounce message, by convention and  by  SMTP  standards,
	will be sent to the envelope sender address that  was  attached  to  the
	original e-mail  message  that  generated  the  bounce.  What  will  the
	original envelope sender address be?

	Because FormMail itself generated  the  original  message,  and  because
	FormMail itself was executed as a child process of the local web  server,
	the original envelope sender address will typi- cally be  whatever  local
	user-ID the local web server is run under, or rather, whatever local  user-ID
	it changes to  after  it starts up.

	For typical Apache installations, the account in question  is,  quite  often,
	the local nobody account. That account name is, in turn, quite  often  and
	quite typically aliased (in the local mail server\'s  aliases  file)  to
	/dev/null, in other words to the obliv- ion black hole.

	The implications here  should  be  apparent.  An  attacker  who  attempts
	to  exploit  FormMail  may  be  easily  able  to  escape  immedi-  ately
	detection by local administrators simply by  exploiting  FormMail\'s  inattention
	to the important detail that within the context  of  Perl  regular  expression
	matching,  periods  mean  some-  thing  other  than   literal   periods.
	Exploitation of this inatten- tion  to  detail  may  allow  an  attacker
	to ``pass\'\' FormMail\'s recipient address check in a very stealthy  fashion.
	Once the attacker has gotten past the recipient check,  at  least  once,
	then he may exploit the email  and/or  realname  vulnerabilities  of  FormMail
	(described above) to also direct copies of his mail mes- sage  to  other
	targeted e-mail addresses.

	Other, perhaps even more interesting variations on this theme  are  also
	possible, and are perhaps even more directly dangerous. A FormMail  installer
	who had defined his @recipients array to:

	     @recipients = (\"ourdomain.tld\");


	in order to allow FormMail to be employed to send mail to  any  user  of
	the ourdomain.tld domain might later  be  unpleasantly  sur-  prised  to
	begin receiving spam  complaints  from  somewhere.tld  users  when  some
	miscreant finally figures out that a recipient address such as:



	passes  the  (right-anchored  only)  regular  expression  match  against
	ourdomain.tld with flying colors, only to subsequently have its  parenthesized
	portion treated as a (non-significant) comment by the local  RFC-conforming
	mail server.[14]

	Yet another aspect of the weakness of FormMail\'s  regular-expres-  sion
	based attempts to validate recipient address strings is its total  insensitivity
	to important lexical aspects of domain names themselves, in  particular,
	domain label boundaries.

	FormMail installers who have elected to use one  or  more  domain  names
	in their definition of the @recipients array may be dis- mayed to  learn
	that the lack of left-anchoring  in  FormMail\'s  reg-  ular  expression
	matching, together with FormMail\'s inattention to  the  importance  and
	significance of domain label boundaries may lead to  exploitation  of  a
	locally-installed FormMail, by outside spammers, to spam users in  other
	domains whose own domain names have right-anchored substrings which  just
	happen to exactly match the local domain  name,  even  though  there  is
	otherwise no rela- tionship between those other domains and the local  domain.

	For example, the following @recipients array definition:

	     @recipients = (\"\");


	clearly allows the local FormMail script which  contains  it  to  direct
	FormMail-generated  e-mail  messages  to  various  users  having  e-mail
	addresses directly within the domain. However  what  may  be  less
	clear is that it also allows FormMail-generated mes- sages to  be  directed
	to  persons  having  e-mail   addresses   within,   for   example,   the domain. More troubling is that it  also  allows  FormMail-generated
	messages to be directed to any  person  having  an  account  in  the  (clearly
	unrelated)  domain.  This   problem   arises   because
	FormMail is not astute enough to understand that, for  example,  the  domain
	name is related to the domain  while  the  domain
	name is entirely unrelated. Thus,  an  instance  of  FormMail
	installed on a web server belonging to could potentially  be  used
	to spam users in  the domain.

	Lastly, as  we  noted  earlier,  one  method  of  circumventing  FormMail\'s
	attempt  to  validate  the  recipient  CGI  parameter  against  elements
	of  the  installer-supplied  @recipients  array   is   to   simply   use
	alternative case for the user ID portion  of  the  client-supplied  recipient
	e-mail address. At the very least, this might allow an attacker  to  use
	FormMail to send  an  e-mail  message  to,  for  example,  a  user  whose
	e-mail address is JOHN@localhost.tld  even  though  the  installer  only
	intended to allow FormMail messages to  go  to  the  user  whose  e-mail
	address is john@localhost.tld.[12]

	This fact alone may be properly  viewed  as  being  essentially  insignificant.
	At worst, the case  insensitivity  of  the  FormMail  recipient  address
	checks would seem to allow misdirection of  FormMail  messages  to  different
	(and unintended) users of the same target recipient  system  where  some
	other valid and authorized FormMail message recipient also has  an  account.

	Recall however that the logic of FormMail demands that at least  one  of
	the comma-separated substrings  of  the  client-supplied  recipient  CGI
	parameter value must in fact `pass\' the  recipient  address  validation
	check. Otherwise no e-mail message  will  be  sent,  regardless  of  whatever
	other  clever  manipulations  an attacker might have undertaken.

	Exploitation of the case-insensitivity of the recipient address  checking
	code may provide yet another means for an attacker to pass the  recipient
	address check, at least once, thus insuring that his desired  e-mail  message
	will in fact be sent by FormMail. Furthermore, it may allow the  recipient
	address check to be bypassed even as it  also  allows  the  attacker  to
	avoid immediate detection of his activities, either  by  any  authorized
	FormMail message recipient or by any local administrator.

	For example, let us suppose that the @recipients array was previ-  ously
	defined by the installer as follows:

	     @recipients = (\"^john\\@our-server.tld\");


	Based on the  other  vulnerabilities  noted  above,  an  attacker  could
	easily spoof his way past the HTTP_REFERER check and he  could  then  provide
	some clever values for either the email CGI parame- ter or  the  realname
	CGI parameter, or both. Those values could induce  FormMail  to  send  a
	desired e-mail message to some  addi-  tional  e-mail  recipient  addresses,
	above and  beyond  whatever  address  may  have  been  provided  by  the
	attacker as the client-sup- plied recipient  CGI  parameter  value.  But
	even if he  does  all  this,  the  attacker  must  still  get  past  the
	script\'s checks on the recipient value, at least once, in order  to  induce
	FormMail to send any e-mail messages at all.

	To get past the checks on the validity  of  the  recipient  CGI  parameter,
	the attacker might set this parameter to the  value  JOHN@our-server.tld.
	This would cause the recipient check to pass, once,  and  that  in  turn
	would enable the script to continue further in  its  processing  of  the
	HTTP request, whereupon  any  of  the  several  other  FormMail  vulnerabilities
	could then be exploited. In such a case however, the  local  mail  server
	would also attempt to send a copy of the attacker\'s message to  the  e-
	mail address JOHN@our-server.tld.  What then?

	In the most common case, i.e. where our-server.tld is in fact the  local
	domain, and where the mail server providing mail service for  the  local
	domain is either Sendmail or Postfix, the attacker  will  typically  not
	be able to  hide  his  activities  via  this  sort  of  case-sensitivity
	exploitation because the local mail server (- Sendmail or Postfix)  will
	actually treat the user ID portion  of  a  local  e-mail  address  in  a
	case-insensitive manner. Thus, even if the attacker tricks  the  FormMail
	script into attempting to send an e-mail message to  JOHN@our-server.tld
	that message will still be delivered to the john@our-server.tld  mailbox.
	The local john user will thus be alerted that the local FormMail  script
	is being used, and possibly abused, and quick remedial action  may  then
	be taken to halt further abuse.

	If however the specific mail server that provides mail  service  for  the
	our-server.tld domain  treats  local  user  IDs  in  a  case-  sensitive
	manner, then the user  ID  john  may  exist,  and  may  accept  incoming
	e-mail, even though the user ID JOHN does not exist and does not  accept

	In this case, any message sent to the JOHN@our-server.tld  account  will
	bounce as undeliverable.  Where will it bounce to?

	As noted previously, the  message  should  be,  and  typically  will  be
	bounced back (along  with  an  undeliverable  notice)  to  its  envelope
	sender address. And as was also previously noted,  the  envelope  sender
	address will almost invariably be the local user  ID  under  which  both
	the local web server and any CGIs that it  invokes  run.  That  account,
	quite often, is the local nobody account, and e- mail for the  local  nobody
	account is, as often as not, aliased to /dev/null. Thus,  if  the  attacker
	arranges to ``pass\'\' the FormMail  recipient  address  validation  test
	by changing the case of the user ID portion  of  some  known  authorized
	recipient e-mail  address,  and  if  the  alternatively-cased  recipient
	address is itself undeliverable, then this may represent an  opportunity
	for the attacker. Specifically, it may allow the attacker to  trick  FormMail
	into believing that it has received at least one valid  recipient  address
	even though the message sent to that address will first  be  bounced  as
	undeliverable  and  then,  subsequently,  will  disappear,  quietly  and
	conveniently, down a black hole, without alerting  any  local  end-users
	or any local administrators on the exploited  system  that  exploitation
	is occurring.

	It should additionally be noted that even in cases where the web  server
	itself is run under some account other  than  the  nobody  account,  the
	account that the web server is in fact run under will  often  and  typically
	be one for which incoming e-mail  messages,  including  bounces,  are  dumped
	into a black hole. Fur- thermore, even for web server execution  accounts
	that are not aliased to /dev/null, local administrators may  not  be  expecting
	any incoming e-mail for the web  server  execution  account,  and  thus,
	any e-mail that does arrive for that account may  be  moni-  tored  only
	rarely or perhaps never. Such a situation is exactly  what  an  attacker
	wishing  to  escape immediate detection would desire.

	In summary, it may safely be said that the case insensitivity of the  FormMail
	recipient address checking code may open up addi-  tional  possibilities
	for quietly covering up abuse and exploita- tion of the  other  FormMail
	security flaws detailed herein.[13]


	Mail-Bombing by Proxy Using FormMail


	Although  exploitation  of  installed  FormMail  scripts  for   spamming
	purposes is far and away the most likely scenario involving mis- use  and
	abuse of FormMail, a desire for completeness compels  us  to  note  some
	additional ways in which typical FormMail installa- tions may be  abused
	to cause harm or annoyance to others, even if only indirectly.

	In general, any Internet miscreant may easily flood any Internet  e-mail
	account of his choosing by simply sending a flood of e- mail messages  directly
	to that target account. This direct approach  is  however  known  to  be
	a good way to have  one\'s  outbound  e-mailing  privileges  revoked  in
	short order.

	Being aware of this fact, many Internet miscreants bent on per-  forming
	an act of mail bombing against a given target e-mail  account  will  instead
	elect to do so only indirectly, employing  some  intermediary  agent  or
	system that can be  induced  to  send  e-  mail  messages  to  arbitrary
	attacker-specified e-mail addresses. To the extent that  the  intermediary
	prevents the final victim of the mail bombing from easily  learning  the
	identity and/or IP address of the mail bomb originator it  will  be  seen
	as a poten- tially useful tool for a stealth mail bomb attack.[15]

	Given these facts, together with the multiple FormMail vulnera-  bilities
	described above, it  should  be  immediately  seen  that  any  installed
	instance of the FormMail script may be  employed,  in  various  ways,  as
	part of a stealth mail bombing attack directed  against  an  arbitrarily
	selected target e-mail address.

	It has certainly been shown above that FormMail may be induced  to  send
	arbitrary messages to arbitrary target addresses in a way which  prevents
	the final recipient from being able to  easily  determine  the  IP  address
	of the actual message originator. This  fact  alone  could  provide  the
	basis for  a  stealth  mail  bombing  attack.  Additional  possibilities
	for  such attacks, involving FormMail, may also exist however.

	For example, if FormMail is being  employed  on  a  given  web  site  in
	conjunction with an e-mail auto-responder of some kind, then it  may  be
	possible for an attacker to repeatedly  invoke  FormMail  while  setting
	the email CGI parameter to the e-mail address of his intended victim.  The
	victim in this case will receive  a  flood  of  ``auto-responses\'\'  for
	messages that he himself did not  originate,  and  these  auto-responses
	may (and quite often will) contain no indication of the  IP  address  that
	originated   whatever   message   or   messages   have   triggered   the
	auto-responder to send a response message. Note also that even for  a  relatively
	``smart\'\' auto-responder that makes it a point to  attach  the  e-mail
	headers of each original triggering e-mail message to each of the  auto-
	response messages it generates, the trace information provided  by  such
	headers will lead back only as far as the web server on the system  that
	hosts the FormMail script. That information will of  course  be  insufficient
	to determine the IP address used by the actual instigator  of  the  mail

	Because of the above scenario, it is strongly recommended  that  FormMail
	never be intentionally employed in conjunction with any kind  of  e-mail



	------------------------------------------------------------   [1]   The
	canonical reference for the original `FormMail spamming\' advisory is:


	Note that even earlier, reports had surfaced regarding FormMail and  environment
	variable information leakage:


	and a fix was developed for this problem:


	A remote command execution vulnerability was also reported  (Aug,  1995)
	for the 1.0 version of FormMail:


	[2] The original report of possible widespread scanning of the  net  for
	vulnerable FormMail scripts may be found at:,3396,s%253D25124%2526a%253D18236,00.asp#story4


	[3] The home page for one allegedly ``fixed\'\' version of FormMail  may
	be found at:


	An  entirely  separate ``fixed\'\' version of FormMail may be found at:


	Unfortunately, neither of these security-enhanced  versions  of  FormMail
	address all of the security issues raised herein.

	[4] Inexplicably, even though versions of FormMail prior to 1.9 are  known
	to be exploitable (as what amounts to anonymizing open mail  relays)  the
	author of this script continues to distribute several  of  his  earlier,
	insecure versions of the script (for use with/on various versions of  MS
	Windows) via his  web  site  and  the  FormMail  home  page.  This  will
	naturally tend to contribute to a worsening of  the  existing  global  problem
	of insecure FormMail installations, over time.

	[5] We use the term anonymized herein to indicate that  the  IP  address
	of the actual message origination point will not be pre- sent in any  of
	the e-mail Received: headers contained in the mes- sage  themselves.  This
	lack of tracing information makes it essentially impossible for  a  message
	recipient to determine the actual origination  point,  at  least  not  without
	the aid of the administrator of the server that hosts the FormMail  script
	and not  without a careful search of log files by that administrator.

	[6] The lynx web browser provides the  -noreferer  command  line  option
	to achieve this exact effect.

	[7] Javascript, in particular, implements a  submit()  built-in  primitive
	that can be used to simplify attacks on web CGIs. The authors  have  found
	no way to induce Javascript\'s submit()  primi-  tive  to  suppress  the
	inclusion of a Referer: header in the HTTP request generated by  a  call
	to submit() however.

	[8] There are, of course, other ways to cause  typical  web  servers  to
	ignore some rightward part of a complete URL.  The  forward  slash  character
	(`/\') can also be used to achieve the same effect when the  portion  of
	the URL to the right of the relevant forward slash can be located  by  the
	relevant web servers and when it is an ordinary file (as  opposed  to  a

	[9] There are, of course, other ways by which one could arrange  for  Referer:
	HTTP headers to be suppressed, the most obvious of which is to make  use
	of any of the  Internet\'s  many  anonymizing HTTP proxy servers.

	[10] One of the  authors  of  this  advisory  (Guilmette)  is  currently
	maintaining a list of the IP addresses of such sites  for  spam  blocking

	[11] Please see:


	for a brief description of the traditional (if non-standard)  per-  cent
	hack e-mail addressing notation.

	[12] Of course, different operating systems have different con-  ventions
	and  practices  with  regards  to  the  case  sensitivity...   or   lack
	thereof... of local user IDs. It should be  noted  however  that  FormMail
	is most frequently installed on UNIX  or  UNIX-like  systems,  and  that
	these systems do, in virtually all cases, treat local user  IDs  as  being
	case sensitive, thus allowing for the possibility that there might be  a
	user whose ID is john and also another user whose ID is  JOHN,  both  on
	the same single system.

	[13] Webmasters may also wish to reconsider the advisability of  running
	web servers under accounts whose  incoming  e-mail  is  either  sent  to
	/dev/null or ignored. It may actually be wiser to  select  some  account
	other than the nobody account to  run  a  web  server  under,  and  then
	to alias that other account to root or some  other  frequently-monitored
	local administrator address. The nobody account should more probably  be
	preserved as an effective e-mail alias for  /dev/null  however,  as  there
	are certainly instances in which you really don\'t want any  bounces,  no
	matter what.

	[14] See RFC 2822, especially its discussion  of  parenthesized  comments
	and e-mail address syntax.

	[15] An indirect mail bomb attack against a given e-mail address may  be
	easily undertaken simply by sending a large number of e-  mail  messages
	to some non-existent and/or otherwise undeliverable  e-mail  address  on
	some specific third-party intermediary system with the  envelope  sender
	(i.e. bounce back) e-mail address set  to  the  e-mail  address  of  the
	intended victim. Such an indirect mail bombing  via  bounces  attack  is
	not at all stealthy however, because in the vast majority of  cases  the
	attacker\'s IP address will be shown clearly  in  the  Received:  headers
	of the messages that triggered the  bounces,  and  these  in  turn  will
	typically be included in the  bounce  messages  received  by  the  final


	A revised version of FormMail 1.9 (which I am  calling  1.9s)  which  is
	believed to be free of any and all of the security  flaws  described  in
	the advisory below is now available at:


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH