|
From: Jonathan S. <gel...@ge...> - 2001-12-04 11:45:10
|
On Mon, 3 Dec 2001, Dave Cross wrote: > Jacqui caren wrote: > > > [posted and mailed] > > > > da...@da... (Dave Cross) wrote in <3C0...@da...>: > > > > > >>http://nms-cgi.sourceforge.net/ > >> > > > > > > First let me say I am impressed by the overall code > > quality - use of strict removal of env vars etc > > and -T makes for an excellent start on security :-) > > > > > > > > Now for the bad part, the first script I looked at has > > the **same** stupid bug that the MSA code has - namely > > it uses sendmail as a delivery subsystem. > > Whilst this will probably be seen as a terminological nit, sendmail isn't being used as a delivery subsystem - it is a Mail Transfer Agent. > > The problem with this is that any ISP (worth thier salt) > > that has some of the sendmail anti-spam hacks enabled. > > if you are unlucky (I say lucky to have a good ISP) > > then this MTA will reject email that purports to originate > > from other than the uid of the process starting the sendmail > > process. Sendmails delivery sub system is a trowover from > > the need to support cron etc - it should not be seen as > > a way to deliver email from and to anyone... > > *gasp* sendmail is probably one of the most secure programs about and probably one of the most wildly used - at a guess I would say that about 75% of all the e-mail in the world is transmitted by a sendmail somewhere along its travels. The point about the 'anti-spam hacks' (well designed privacy controls shurely) as I understand it is that this only applies to the envelope address that can be set with the -f switch : any 'from' address in the headers of the message is not affected. A sendmail running on a webserver will probably not be running as a daemon on a well configured system anyhow and will only be used for mail injection so there is little need to implement any of the more stringent spam controls that one would have on a mailserver. Anyhow there are people here who know more about sendmail than I do. > > You pass in email addresses via cgi params - would it not > > be preferable to use soemthing a bit more secure? > > > > IMHO It is all well and good to try and be a drop-in > > replacement however leaving the MSA security holes > > to keep drop-inability is unacceptable. > > > > My worry with thsi is that a large value in $username > > that holds an EOT char could **possibly** execute a sequence > > of system commands given your shell wrapper under unixen > > systems. > > Whats an EOT char ? /J\ -- Jonathan Stowe | <http://www.gellyfish.com> | This space for rent | |