Topic awaiting preservation: Email header injection for Suho (Page 2 of 2)

void(0);



(Edited by poi on 03-20-2006 11:45)

Ok, so for having been pragmatic in my advice, having covered all possible security gaps, having suspected a flaw
in OB's script, mentionned it jokingly after having several tracks that tend to prove it can be done,
received insults in return, I am supposed to be the bad guy,
and am challenged to discover or rediscover, and publicly disclose an additional header injection flaw?

And to spend hours on that?
While I have a cutie to cherrish and work around the clock for the week, or the next 10 days even?
That's what I "get" for using my time to help?

Well, believe it or not, 100$ an hour is what I cost already (not what I earn sadly). The rest of the "payback"
is not worth it: I have nothing to prove.

Listen, leave out "any field" you would like to leave out, I was glad to help at first, but you're making it painful.

Whoa, easy there

Never said anything about anyone being the bad guy. Or about anyone having any obligation here.

Just saying OB is not entirely at fault here, and being someone who does not understand these security issues very well, would love to see the results of someone going after his script.

My apologies for that outburst. Scarcely exemplary behavior. Sigh. I'm a sadly humorless and pragmatic stage of life with little patience for the sport of sparing. Sorry.

Let's for the sake of argument let's say that OpticBurn's approach *is* immune from the injection attack. I don't have the resources or the knowledge to prove either way. Whether it works or not is of academic interest. It is still not what I would consider an optimal solution for the average person who wants a simple, functional mail form on their site. It generates a non-working reply-to address. One would have to copy and paste the reply-to information from the mail message in order to respond to this person.

This is less than optimal for the average site owner for two reasons. First: it's harder. The average person wants to get something in their in box that they can read and reply to easily, using the techniques they are accustomed to. Second: if the form *is* the subject of an injection attack it's still going to show up in your inbox, probably with a message cluttered dozens of E-mail addresses and most likely with whatever evil attachment the spammer is trying to send.

Am I wrong? OpticBurn's script might prevent the mail form from being used as a relay. It might prevent the hacked message from being sent to dozens of victims, but the mail form owner still gets it. Right? So one important purpose of validating the user input is to abort the mail altogether if an attempt is made to misuse it.

Please correct me if I totally misunderstood OpticBurn's suggested code.

OB's leaving out a possible entry point, leaving a gap between onion layers and assuming it is safe.
I still deeply think it's not, but the more I think of it, the less I want to try it.

For several reasons: if no exploit has been discovered so far regarding this issue, the risk here is openning up a new can of worms.
Plus it's something I don't like to do. Tracking exploits is not my main goal in informatics.
Plus the challenge is put in such a way: I've done my share of good here, and it worked, so it really is painful to take a share of insults
and play OB's game.

I'll expose what I now as of today, though:
- injecting control ascii chars in any field of the mail function is possible
- as it is processed as a string by MTA (mail transfer agents), injecting the NUL char (0) stops the MTA from receiving the message
- this can cause faulty behavior if the MTA expects a string of a certain length
- other MTAs may react differently on other control chars, leading to other vulnerabilities

However, MTA behavior is dependant on several factors: MTA software, config, and OS namely, and there are a variety of flavors
of each one of those parameters.

Some of the latest links I posted tend to prove some people were able to abuse unexpected form fields, aside the to, from and subject,
to do unpredicted thinks, to add to the probability of someone being able to use the message body.

...

The bug tracking/investigation process I am challenged to perform includes selecting a bunch of MTAs, setting up a bunch of different Linux configs, and thoroughly testing them against several control chars combinations.

So I may, or may not, get back to it, the effort is huge, the consequencies may suck, and the request and corresponding reward
are a bit agressive to my taste.

Steve/Mauro - I appreciate the clarifications/explanations. =)

I used to do a similar method to OB's, however I also did validation on the fields.

The problem is clients wanted to be able to press reply to respond to the hundreds of emails they get, so whil OB has made a point (and there is some validity too it, im sure you can all see his point) - another point to consider is it does lower the usabilty for the people recieving the email.


To my understand all email programs will only use the reply buttons to the reply address in the email header? (i think this is right?)

But hey if its a one way form where people won't be replying, then for the extra security factor (on some systems/versions etc) - you might as well hard code a header.


Validation will always be required in some form, you just have to watch also that your validation script/function isn't vulnerable itself also. I think this has pretty much been covered by Mauro in this post.

Just wanted to make it official: five days after adding the functions recommended by _Mauro, I am still header injection free! I think it's safe to say that everything is working and the spammers have been foiled. So, thanks again for the help. It is greatly appreciated.


___________________________
Suho: www.liminality.org | Cell 270 | Sig Rotator | the Fellowship of Sup