[IMC-NYC-Editorial] beyond dada

[Chris Anderson]

So the security holes are the last straw, as far as
I'm concerned. Can we come up with an organized game
plan to move NYC-IMC off dada?

Chris

--- mike castleman <m at mlcastle.net> wrote:

> (this message contains information intended for
> several different
> audiences, but it's now past 3am and I only feel
> like writing one
> message, so please skip over anything not relevant
> to or understandable
> by you.)
> 
> so, I believe that the cross-site scripting
> vulnerability described at
> rightwingextremist[1,2] has been fixed on
> nyc.indymedia.org. A patch for
> the problem, to be applied to
> imc_classes/imc_Article.inc , is attached
> to this message; IT IS RECOMMENDED THAT ALL SITES
> RUNNING DADAIMC PATCH
> AS SOON AS POSSIBLE, OR SOONER.
> 
> it is also recommended that sites running dadaIMC
> check to see if they 
> have already been exploited. the best way to do so
> is to open up the 
> MySQL client program so you can manually run SQL.
> 
> first, check if anyone's exploited you or not:
> > select objectid, author from articles where author
> like '%<script>%';
> (this may take a little while, because there is no
> index on the author 
> column)
> 
> if no results are returned, feel lucky, apply the
> patch, and move on. 
> otherwise, you need to delete the offending
> articles. deleting them
> (even with the purge option) from the web interface
> is insufficiently
> good, because the message placed on the "article
> deleted" page will by
> default show the author of the deleted article --
> exactly what we wish 
> to avoid. so, do:
> > delete from articles where author like
> '%<script>%'; 
> 
> if you want, you can now add an entry to the
> objections database. note 
> the objectid's returned in the select query above,
> then, for each one do 
> something like:
> > insert into objections
>
(refid,type,title,user,dissent,deletion,deletion_code,deletion_notes,hide,newid)
> values (12345, 'Article', 'DELETED', 'your name', 0,
> 1, 'Policy Violation', 'JS tomfoolery', 0, 0);
> where 12345 should be replaced with the objectid,
> and 'your name' can be 
> replaced with your name if you want.
> 
> if you admin a dadaIMC site, and any of this doesn't
> make sense, contact 
> me (by email, telephone, or find me on irc as mlc),
> and I'll help you 
> through it. it's important that this bug get
> patched.
> 
> so, since this bug has been fixed, I've re-enabled
> posting to the
> nyc.indy newswire. let the trolling begin again!
> 
> it's not clear how far the attackers got. none of
> the scripts I saw did
> anything more than put message boxes on the user's
> screen, but I suppose
> a truly clever attacker could've stolen the session
> of someone with an
> admin account, then removed all evidence of that
> particular attack.
> 
> i've deleted all existing PHP sessions and also
> switched the session 
> handler to MySQL (the former in some probably futile
> attempt to do 
> damage-control; the latter to hopefully boost
> efficiency a bit). if 
> anyone would like my code for this, I'll be happy to
> provide it.
> 
> however, there is some other cookie called userid
> which appears to 
> actually control access. I can't figure out exactly
> how it works, but it 
> seems that if any userid's for admins were stolen,
> it would be bad 
> indeed.
> 
> 
> 
> the only surprising thing about this bug is how long
> it took to find it. 
> it's an almost textbook case of a class of security
> hole called a 
> cross-site scripting vulnerability.
> 
> as I was fixing this bug, I had occasion to read
> over some of the 
> dadaIMC code, and I'm fairly confident is saying
> that more exploitable 
> security holes remain. for example:
> 
>  * the PHP manual explicitly states[3] (and with
> good reason) that using
> the extract() function on $_POST is a bad idea.
> dadaIMC does so 65
> times. it might be possible a malicious user to
> overwrite global 
> variables, with possibly dangerous results. if it's
> not possible, it's 
> probably good luck rather than good design, unless I
> totally missed 
> something.
> 
>  * there is little-to-no checking done on form field
> input. so, as far 
> as I can tell, the user agent is trusted to provide
> a valid value for 
> the Category dropdown, etc. it might or might not be
> possible for even a 
> malicious user-agent to cause anything more than an
> error message from 
> MySQL, but I don't know.
> 
>  * there are still references to crypt()d IPs in the
> dadaIMC code. I 
> don't know if this is actually used anywhere or not,
> but as I've been 
> saying[4] literally for years, this is no better
> than using IPs, and we 
> all (should) know by now why this is a bad idea.
> 
>  * related, the file /var/log/apache/nyc/dadaphp.log
> on tadodaho
> contains IP addresses of clients that cause certain
> classes of error.
> this is not a good thing even to have, and certainly
> not to keep around.
> I don't know how this file is written to, and don't
> really feel like
> looking into it right now, but this is obviously
> very bad.
> 
> it's just not apparent that dadaIMC was "designed
> from the ground-up
> with security in mind", as they say in
> buzzword-land. it makes me
> nervous to be running code about which this can be
> said on a production
> webserver for a very popular website with many
> people who consider
> themselves to be that website's enemy.
> 
> lessons learned: I strongly recommend that:
>  * security audits of popular IMC codebases be done,
> and any bugs found 
>    fixed, and
>  * unless my intuition is wrong and dadaIMC is
> pretty close to secure, 
>    we in NYC move away from it.
> 
> 
> later,
> mike
> 
> [1] http://shorterlink.com/?9F7H3P
> [2]
>
http://lists.indymedia.org/pipermail/imc-tech/2004-October/1018-da.html
> [3]
> http://us2.php.net/manual/en/function.extract.php
> [4] http://shorterlink.com/?7ATC3O
> 
> -- 
> mike castleman, m at mlcastle.net
> http://mlcastle.net/ - tel:+1-646-382-7220
> $ make install not war
> > --- imc_Article.inc.insecure	2004-10-19
> 01:31:46.000000000 +0000
> +++ imc_Article.inc	2004-10-19 04:06:14.000000000
> +0000
> @@ -303,9 +303,12 @@
>  		return ($this->edit_datetime->get_date_short());
>  	}
>  	
> +	// hackery 18 oct 2004 mlc -- attempt to close
> some XSS bugs by
> +	// actually validating input which comes in from
> an untrusted
> +	// source over the Internet. shocking, ain't it?
>  	function read_args() {
>  		$this->read_object_args();
> -		if (!empty($_POST)) extract($_POST);
> +		if (!empty($_POST)) extract($_POST, EXTR_SKIP);
>  		// set the date created for comments (comment
> form, which is often cached, can't use a hidden
> field for this)
>  		if (!isset($this->date_created)) {
>  			$creationdate = new Date(time());
> @@ -316,19 +319,19 @@
>  			$editdate = new Date(time());
>  			$this->set_edit_datetime($editdate);
>  		}
> -		if (isset($form_section))
> $this->set_section($form_section);
> -		if (isset($form_language))
> $this->set_language($form_language);
> +		if (isset($form_section))
>
$this->set_section(htmlentities(cleantext($form_section)));
> +		if (isset($form_language))
>
$this->set_language(htmlentities(cleantext($form_language)));
>  		if (isset($form_category_ids))
> $this->set_category_ids($form_category_ids);
> -		if (isset($form_author))
> $this->set_author($form_author);
> -		if (isset($form_contact_email))
> $this->set_contact_email($form_contact_email);
> -		if (isset($form_contact_phone))
> $this->set_contact_phone($form_contact_phone);
> -		if (isset($form_contact_address))
> $this->set_contact_address($form_contact_address);
> +		if (isset($form_author))
>
$this->set_author(htmlentities(cleantext($form_author)));
> +		if (isset($form_contact_email))
>
$this->set_contact_email(htmlentities(cleantext($form_contact_email)));
> +		if (isset($form_contact_phone))
>
$this->set_contact_phone(htmlentities(cleantext($form_contact_phone)));
> +		if (isset($form_contact_address))
>
$this->set_contact_address(htmlentities(cleantext($form_contact_address)));
>  		if (isset($form_heading))
>
$this->set_heading(cleantext($form_heading,$this->language));
> -		if (isset($form_mime_type))
> $this->set_mime_type($form_mime_type);
> +		if (isset($form_mime_type))
>
$this->set_mime_type(htmlentities(cleantext($form_mime_type)));
>  		if (isset($form_summary))
>
$this->set_summary(cleantext($form_summary,$this->language));
>  		//if (isset($form_body))
> $this->set_body($form_body);
>  		if (isset($form_body))
>
$this->set_body(cleantext($form_body,$this->language));
> -		if (isset($form_parentid))
> $this->set_parentid($form_parentid);
> +		if (isset($form_parentid))
>
$this->set_parentid(htmlentities(cleantext($form_parentid)));
>  		if (isset($form_media))
> $this->set_media($form_media);
>  		if (isset($form_submitted))
> $this->set_submitted($form_submitted);
>  		if (isset($form_displayable))
> $this->set_displayable($form_displayable);
> 

> ATTACHMENT part 1.2 application/pgp-signature 
> _______________________________________________
> imc-nyc-editorial mailing list
> imc-nyc-editorial at lists.indymedia.org
>
http://lists.indymedia.org/mailman/listinfo/imc-nyc-editorial
> 


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail