[geeklog-devtalk] geeklog-devel digest, Vol 1 #252 - 6 msgs

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. PHP in Static Pages (Dirk Haun)
   2. Re: PHP in Static Pages (Tony Bibbs)
   3. Re: PHP in Static Pages (Dirk Haun)
   4. Re: PHP in Static Pages (Tony Bibbs)
   5. Offline (Tony Bibbs)
   6. Re: PHP in Static Pages (Dirk Haun)

--__--__--

Message: 1
From: "Dirk Haun" <dirk at haun-online.de>
To: "Geeklog Devel" <geeklog-devel at lists.geeklog.net>
Date: Tue, 13 Jan 2004 21:26:24 +0100
Organization: Terra Software Systems
Subject: [geeklog-devel] PHP in Static Pages
Reply-To: geeklog-devel at lists.geeklog.net

(moving this to the list from private email)

Tony wrote:


>Have we considered the possibility of stripping calls to certain php 

>functions?  I know we turn PHP off by default and have documented how 

>enabled PHP could be stupid (especially considering most GL logins don't 

>occur over SSL).  Specifically, exec(), system() and some of the 

>filesystem methods should probably be removed or, at the very least, 

>generated emails to the GL admin when they are found.


I can't see how you would do this (reliably) without adding a PHP parser
to Geeklog.


There is a feature request that suggests limiting PHP to only call
certain functions (prefixed with phpstatic_):
<http://project.geeklog.net/tracker/index.php?
func=detail&aid=83&group_id=6&atid=108>

Looks like the intention was to make it similar to PHP blocks.



>Just thinking of ways to be more proactive security-wise with this. 

>Personally I hate seeing PHP in static pages...but I grudgingly conceded 

>considering users seem to insist on having it.


I guess an option in the static pages' config.php to disable PHP
altogether can't hurt ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/


--__--__--

Message: 2
Date: Tue, 13 Jan 2004 15:29:19 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] PHP in Static Pages
Reply-To: geeklog-devel at lists.geeklog.net

 > I can't see how you would do this (reliably) without adding a PHP
 > parser to Geeklog.

Actually the best way to prevent this is when you save the static page.

So, what I am thinking is you would have something like this in the 
static pages config file:

$_SP_CONF['illegal_php_functions'] = 
array('exec','system','chmod','chown','copy','delete','chgrp','fileperms','fileowner','fopen',etc);

Then we would scan the static page db fields for any of those. Note you 
would have to be bit careful when doing this as you want to find 
instances of 'delete (' and 'delete(' not just 'delete'.  When any of 
those are encountered it should log the user and the page ID.

If you want to get ultra paranoid, you could also check it at the static 
page execution level too.  I assume that static pages execute php just 
like COM_siteHeader() does so in that case you have some code like this:

<snip>
ob_start();
eval( '?>' . $tmp );
$retval = ob_get_contents();
ob_end_clean();
</snip>

So you could apply the check on $tmp prior to the call to eval().

--Tony

Dirk Haun wrote:

> (moving this to the list from private email)

> 

> Tony wrote:

> 

> 

>>Have we considered the possibility of stripping calls to certain php 

>>functions?  I know we turn PHP off by default and have documented how 

>>enabled PHP could be stupid (especially considering most GL logins don't 

>>occur over SSL).  Specifically, exec(), system() and some of the 

>>filesystem methods should probably be removed or, at the very least, 

>>generated emails to the GL admin when they are found.

> 

> 



> 

> 

> There is a feature request that suggests limiting PHP to only call

> certain functions (prefixed with phpstatic_):

> <http://project.geeklog.net/tracker/index.php?

> func=detail&aid=83&group_id=6&atid=108>

> 

> Looks like the intention was to make it similar to PHP blocks.

> 

> 

> 

>>Just thinking of ways to be more proactive security-wise with this. 

>>Personally I hate seeing PHP in static pages...but I grudgingly conceded 

>>considering users seem to insist on having it.

> 

> 

> I guess an option in the static pages' config.php to disable PHP

> altogether can't hurt ...

> 

> bye, Dirk

> 

> 



--__--__--

Message: 3
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] PHP in Static Pages
Date: Tue, 13 Jan 2004 22:53:52 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony wrote:


>Then we would scan the static page db fields for any of those. Note you 

>would have to be bit careful when doing this as you want to find 

>instances of 'delete (' and 'delete(' not just 'delete'.


So we would also catch

    echo "You can't use delete() in static pages.";

There may also be less-than-obvious ways to bury those "dangerous" PHP
statements in a static page and still have them executed.



>When any of 

>those are encountered it should log the user and the page ID.


So the first thing to do when you hijack a static page is to delete the
error.log from it.


I guess a security audit of the plugin is in order, but, as I said
before, I don't think you can reliably catch all cases.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/


--__--__--

Message: 4
Date: Tue, 13 Jan 2004 16:47:40 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] PHP in Static Pages
Reply-To: geeklog-devel at lists.geeklog.net

Dirk Haun wrote:

> echo "You can't use delete() in static pages.";


Yeah, but that is no different, IMHO, than the censorship filters we 
have now to catch 'bad' words.  If users are using thigns like 
'delete()' in the static page then they would simply go to the config 
and remove it if they really need it.  Point is we would be erroring on 
the side of security yet allowing users a way to remove this checking 
altogether.


> 

> So the first thing to do when you hijack a static page is to delete the

> error.log from it.

> 


LOL, I suppose.  IMHO, you don't even have to prevent the use of any PHP 
functions that may be questionable.  Maybe the first place to start is 
to proactively log when a page is saved by saying "hey, someone just 
saved a static page and we think it had things like delete() and chgrp() 
in it".


> 

> I guess a security audit of the plugin is in order, but, as I said

> before, I don't think you can reliably catch all cases.

> 


Maybe, I'm not dinging the thing...I'm just bringing back to light 
issues we should consider.  Again, the secure way to handle this is to 
not have PHP in static pages to begin with but given we now endorse this 
possiblity we should consider ways to harden especially considering that 
we are becoming more and more popular with blackhats.

Which reminds me, do we have that bozo doing SQL injection attempts on 
GL.net still?

--Tony


--__--__--

Message: 5
Date: Tue, 13 Jan 2004 16:50:06 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: Geeklog <geeklog-devel at lists.geeklog.net>
Subject: [geeklog-devel] Offline
Reply-To: geeklog-devel at lists.geeklog.net

I will be offline for an out of town wedding until Tuesday of next week.

Chow,

--Tony


--__--__--

Message: 6
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] PHP in Static Pages
Date: Wed, 14 Jan 2004 08:00:04 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony wrote:


>Maybe, I'm not dinging the thing...I'm just bringing back to light 

>issues we should consider.


np, I was just playing the Devil's Advocate.



>Again, the secure way to handle this is to 

>not have PHP in static pages to begin with but given we now endorse this 

>possiblity we should consider ways to harden especially considering that 

>we are becoming more and more popular with blackhats.


Yep. An option to switch off PHP from the config file would be a start.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest