Re: mysterious line in my script - what does it all mean?

Paul Lalli wrote:
l v wrote:
Paul Lalli wrote:
above program prints USER-ENTERED DATA in the headers of the mail
message. This data is not verified before being printed. Just because
the *programmer* only put a hard-coded address as a To: header, does
not mean the data will not contain additional headers. You honestly
don't think a user could access this script providing a 's' parameter
of "me@xxxxxxxxxxx\nCC: spam_address@xxxxxxxxxxx" ?

I am not seeing this behavior in my testing of what you state. All I
get is an email with a sender which has the following format.


You seem to be under the very bizzare (and very wrong) impression that
the form which was designed to contact this CGI script is the only way
to contact the CGI script.

That, or you just neglected the \ before the n. One of the two.

Does the spamming problem you speak of go away if using a module like

Of course not. This is programmer stupidity, not code stupidity.

What I am trying to say is that the exploit depends on generating extra header simply by adding a newline and the extra header. Using a module like Mail::Sender should not generate the extra header. Correct?

I am assuming Mail::Sender may do some form of validity
checking (tainting) according to the RFC's.

What? Why would Mail::Sender do any taint checking? And what does
taint checking have to do with the RFC's? And what do the RFC's have
to do with this problem?

Paul Lalli

The RFC's for smtp details the smtp protocol which includes format of the headers.
The headers should terminate with CRLF.
Modules like Mail::Sender should adhere to the smtp protocol defined in the RFC's.

With those 3 points in mind, it would *seem* to me if I set Mail::Sender's 'from' = "me@xxxxxxxxxxx\nCC: spam_address@xxxxxxxxxxx", either Mail::Sender should either:
generate an error,
use the 'from' value in it's entirety as the 'from' header,
truncate after the first newline,
or everything past newline is ignored when creating the smtp commands.

My choice would be use the 'from' value in it's entirety as the 'from' header. IMO, sendmail should never be called via cgi which would also prevent 2000-byte binaries from causing sendmail to crash leaving shell's left open.

I also believe that if we are to get the upper leg on the spammers, we can not leave the responsibility in the hands of the programmer - as you state, programmers can be stupid FTTT.



Relevant Pages

  • Re: PC-Lint complains about this code, but I dont know whats wrong with it (PC-Lint error #1
    ... that broke the compiler. ... Instead of telling the programmer ... Every header is *required* to #include everything it needs. ... successful companies are perhaps worthy of your consideration.) ...
  • Re: Location header question
    ... >> Location header, but you still think you should carry on this way? ... > Laziness is supposed to be a virtue in programmers. ... All else is a potential grey area - even if the spec were to be ... the lazy programmer would do well to avoid pointless extra work by ...
  • Re: P5Q Premium bios chip
    ... The BIOS chip is next to the TPM header. ... You would need an SPI programmer, ...
  • Re: Experience with g++ 4.2.0 on AIX 5.3
    ... Have you ever considered that some other programmer had to deal with it before you could just type the commands? ... I tried to recompile gcc a couple of days ago and initially I had problems with buggy headers from IBM. ... E.g. header file was missing the header and still had a #endif at the bottom... ...
  • Re: #includes in header files
    ... I once read that it's not a good programming style to #include in header files, where structs, typedefs or functions are declared. ... rather than forcing the programmer to keep track of that dependency in ... dependencies and you have to grovel through each one to find out. ...