Menu
▾
▴
phpicalendar-devel
|
From: Scott G. <sg...@in...> - 2006-03-23 14:22:28
|
I received this advisory from Secunia a couple of days ago and wonder if it has been fixed yet? I'm not seeing any discussion of it here or on the message board: http://secunia.com/advisories/19285/ If this is just the same issue that was fixed with this patch: http://phpicalendar.net/forums/viewtopic.php?t=396&sid=fe5fe3f127aadecad7c0016108357259 please let me know. I have disabled a public PHPiCal installation temporarily until I know for sure. Thanks, Scott -- Scott Garman sgarman at iname dot com |
|
From: Jim Hu <ji...@ta...> - 2006-03-23 16:28:47
|
Scott, Thanks, I wish they would let us know before publishing on their website. :^( Glad you are subscribed to their alerts. Vuln #1 is from cookies, and I posted a temporary filling on the bbs - comment out the code that reads the cookie in init.inc.php. Vuln #2 is related to the publish scripts, which we technically say we don't support. We may need someone to take this on. Anybody? Getting back to #1, we really should not be using any superglobals without verifying their content. I've been thinking this for a while. I suggest that this should be a high priority item. The approach I am thinking of is a script that runs early that reads all of these, checks their content, and throws a breakin attempt error if anything looks inappropriate. There are two approaches to this: 1) Rewrite the content of the superglobals we use. This is probably not a good way, since as we add code, we may add a new $_GET or $_REQUEST that isn't checked. 2) Move all the validated content into a new array $clean[$key] (or some other array name) and then unset the other superglobals after the validation script runs. This is my preferred method, but it means that we may frustrate people who are trying to add new features or customize their code. What do people think? Jim ===================================== On Mar 23, 2006, at 8:22 AM, Scott Garman wrote: > I received this advisory from Secunia a couple of days ago and > wonder if it has been fixed yet? I'm not seeing any discussion of > it here or on the message board: > > http://secunia.com/advisories/19285/ > > If this is just the same issue that was fixed with this patch: > > http://phpicalendar.net/forums/viewtopic.php? > t=396&sid=fe5fe3f127aadecad7c0016108357259 > > please let me know. I have disabled a public PHPiCal installation > temporarily until I know for sure. > > Thanks, > > Scott > > -- > Scott Garman > sgarman at iname dot com > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Wesley M. <we...@we...> - 2006-03-25 07:15:31
|
We could use the approach required by taint-mode in Perl, where any inputs from the user must pass through your grep patterns and be pulled into separate values from the matching values. I guess this would work by having a separate function that is the only place in PHP iCalendar that can access _GET, _REQUEST, or cookies, and it will return an array of the values it has pulled out of any of those inputs. This would isolate things and make it easy to identify code that isn't following this rule. On Mar 23, 2006, at 8:28 AM, Jim Hu wrote: > > Getting back to #1, we really should not be using any superglobals > without verifying their content. I've been thinking this for a > while. I suggest that this should be a high priority item. The > approach I am thinking of is a script that runs early that reads > all of these, checks their content, and throws a breakin attempt > error if anything looks inappropriate. There are two approaches to > this: > > 1) Rewrite the content of the superglobals we use. This is > probably not a good way, since as we add code, we may add a new > $_GET or $_REQUEST that isn't checked. > 2) Move all the validated content into a new array $clean[$key] (or > some other array name) and then unset the other superglobals after > the validation script runs. This is my preferred method, but it > means that we may frustrate people who are trying to add new > features or customize their code. -- Wesley Miaw we...@we... |
|
From: Jo R. <jr...@sv...> - 2006-04-28 02:43:42
|
On Thu, Mar 23, 2006 at 10:28:09AM -0600, Jim Hu wrote: > Vuln #2 is related to the publish scripts, which we technically say > we don't support. We may need someone to take this on. Anybody? I'll own it. But I doubt I can start before Sunday. (and yes, I'm a month late answering) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation |
|
From: Jim Hu <ji...@ta...> - 2006-03-25 07:55:57
|
On Mar 25, 2006, at 1:15 AM, Wesley Miaw wrote: > We could use the approach required by taint-mode in Perl, where any > inputs from the user must pass through your grep patterns and be > pulled into separate values from the matching values. I guess this > would work by having a separate function that is the only place in > PHP iCalendar that can access _GET, _REQUEST, or cookies, and it > will return an array of the values it has pulled out of any of > those inputs. This would isolate things and make it easy to > identify code that isn't following this rule. I think we could accomplish this by putting a module of this kind as a require_once from init.inc.php. We'd move the cookie stuff into it. I'm not very good with regex, though...so help is needed! Anyone know if there a good module we could use for this from PEAR or elsewhere? I propose that 2.2x continue to be minor tweaks of what we currently have, and this be a goal for 2.3. If danon is still working on his improved admin page, I think this will be needed. Jim > > On Mar 23, 2006, at 8:28 AM, Jim Hu wrote: >> >> Getting back to #1, we really should not be using any superglobals >> without verifying their content. I've been thinking this for a >> while. I suggest that this should be a high priority item. The >> approach I am thinking of is a script that runs early that reads >> all of these, checks their content, and throws a breakin attempt >> error if anything looks inappropriate. There are two approaches >> to this: >> >> 1) Rewrite the content of the superglobals we use. This is >> probably not a good way, since as we add code, we may add a new >> $_GET or $_REQUEST that isn't checked. >> 2) Move all the validated content into a new array $clean[$key] >> (or some other array name) and then unset the other superglobals >> after the validation script runs. This is my preferred method, >> but it means that we may frustrate people who are trying to add >> new features or customize their code. > > -- > Wesley Miaw > we...@we... > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Nicolas C. <ni...@co...> - 2006-04-28 09:16:04
|
MjAwNi8zLzI1LCBKaW0gSHUgPGppbWh1QHRhbXUuZWR1PjoKPiBPbiBNYXIgMjUsIDIwMDYsIGF0 IDE6MTUgQU0sIFdlc2xleSBNaWF3IHdyb3RlOgo+Cj4gSWYgZGFub24gaXMgc3RpbGwgd29ya2lu ZyBvbiBoaXMgaW1wcm92ZWQgYWRtaW4gcGFnZSwgSSB0aGluayB0aGlzCj4gd2lsbCBiZSBuZWVk ZWQuCgpZZXMgaSdtIHN0aWxsIHdvcmtpbmcgb24gaXQgKGh1bS4uLikKQWZ0ZXIgcmVhZGluZyB0 aGlzIHRocmVhZCAoT2tpLCBJJ20gYSBiaXQgbGF0ZSB0byByZWFjdCB0b28pLCBJIGRvbid0Cmtu b3cgd2hpY2ggaXMgdGhlIGJlc3Qgd2F5IHRvIGZvbGxvdy4KCkkndmUgdG8gZ28gYmFjayB0byB0 aGUgY29kZSB0byBzZWUgaG93IGJpZyBhcmUgdGhlIHVzZXMgb2Ygc3VwZXJnbG9iYWxzLgpGb3Ig bm93LCBJIGFuYWx5emVkIHVzZXIncyBpbnB1dCBteXNlbGYsIGluIHRoZSBhZG1pbiBhcmVhLi4u CgpoYXMgYW55Ym9keSBldmVyIHN0YXJ0ZWQgd29ya2luZyBvbiBpdCA/IGlmIHNvLCB3aGF0IGlz c3VlIGRpZCB5b3UKY2hvb3NlID8gSSdsbCBmb2xsb3cgeW91ciB3b3JrLgoKCkRhbm9uJy4KLS0K SSdtIGEgcG9vciBhbmQgbG9uZXNvbWUgWWFvdXJ0Li4uIChBaXIgY29ubnUpCg== |
|
From: Jim Hu <ji...@ta...> - 2006-04-28 04:02:53
|
Great, thanks! Jim On Apr 27, 2006, at 9:42 PM, Jo Rhett wrote: > On Thu, Mar 23, 2006 at 10:28:09AM -0600, Jim Hu wrote: >> Vuln #2 is related to the publish scripts, which we technically say >> we don't support. We may need someone to take this on. Anybody? > > I'll own it. But I doubt I can start before Sunday. (and yes, I'm > a month > late answering) > > -- > Jo Rhett > senior geek > SVcolo : Silicon Valley Colocation |
|
From: Jo R. <jr...@sv...> - 2006-09-16 22:25:49
Attachments:
publish.php
|
> >On Thu, Mar 23, 2006 at 10:28:09AM -0600, Jim Hu wrote: > >>Vuln #2 is related to the publish scripts, which we technically say > >>we don't support. We may need someone to take this on. Anybody? > On Apr 27, 2006, at 9:42 PM, Jo Rhett wrote: > >I'll own it. My apologies for the extreme late delay getting to this. Attached is an updated publish.php. It has the following changes: 1. It fixes the security problem mentioned above. 2. It integrates publish.ical.php and publish.mozilla.php into a single file again. No need to have two files. 3. It supports external authentication (ie .htaccess) for CGI users 4. It supports php authentication with mod_rewrite but without mod_php 5. Logging is improved 6. Internal Documentation is updated and clarified for Sunbird/Lightning users. (the docs may not work for old Mozilla cal users, but I don't know anyone who still has this -- testers?) 7. Minor code cleanup to be consistent with the rest of the code base. And from this point forward I'll start looking at bugs in the sourceforge system and taking on those related to publish. Sorry for the delay. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation |
|
From: Jim Hu <ji...@ta...> - 2006-09-16 22:43:08
|
Thanks...don't sweat the delay, for the princely sum we get paid for this, I think we're doing OK! ===================================== Jim Hu On Sep 16, 2006, at 5:24 PM, Jo Rhett wrote: >>> On Thu, Mar 23, 2006 at 10:28:09AM -0600, Jim Hu wrote: >>>> Vuln #2 is related to the publish scripts, which we technically say >>>> we don't support. We may need someone to take this on. Anybody? > >> On Apr 27, 2006, at 9:42 PM, Jo Rhett wrote: >>> I'll own it. > > My apologies for the extreme late delay getting to this. > > Attached is an updated publish.php. It has the following changes: > > 1. It fixes the security problem mentioned above. > > 2. It integrates publish.ical.php and publish.mozilla.php into a > single > file again. No need to have two files. > > 3. It supports external authentication (ie .htaccess) for CGI users > > 4. It supports php authentication with mod_rewrite but without mod_php > > 5. Logging is improved > > 6. Internal Documentation is updated and clarified for Sunbird/ > Lightning > users. (the docs may not work for old Mozilla cal users, but I > don't know > anyone who still has this -- testers?) > > 7. Minor code cleanup to be consistent with the rest of the code base. > > And from this point forward I'll start looking at bugs in the > sourceforge > system and taking on those related to publish. Sorry for the delay. > > -- > Jo Rhett > senior geek > SVcolo : Silicon Valley Colocation > <publish.php> > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ > _________________ > Phpicalendar-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel |
|
From: Jo R. <jr...@sv...> - 2006-09-17 01:59:46
Attachments:
publish.php
|
FYI, I've already added a bunch of little patches. Here is the latest.
On Sat, Sep 16, 2006 at 03:24:20PM -0700, Jo Rhett wrote:
> > >On Thu, Mar 23, 2006 at 10:28:09AM -0600, Jim Hu wrote:
> > >>Vuln #2 is related to the publish scripts, which we technically say
> > >>we don't support. We may need someone to take this on. Anybody?
>
> > On Apr 27, 2006, at 9:42 PM, Jo Rhett wrote:
> > >I'll own it.
>
> My apologies for the extreme late delay getting to this.
>
> Attached is an updated publish.php. It has the following changes:
>
> 1. It fixes the security problem mentioned above.
>
> 2. It integrates publish.ical.php and publish.mozilla.php into a single
> file again. No need to have two files.
>
> 3. It supports external authentication (ie .htaccess) for CGI users
>
> 4. It supports php authentication with mod_rewrite but without mod_php
>
> 5. Logging is improved
>
> 6. Internal Documentation is updated and clarified for Sunbird/Lightning
> users. (the docs may not work for old Mozilla cal users, but I don't know
> anyone who still has this -- testers?)
>
> 7. Minor code cleanup to be consistent with the rest of the code base.
>
> And from this point forward I'll start looking at bugs in the sourceforge
> system and taking on those related to publish. Sorry for the delay.
>
> --
> Jo Rhett
> senior geek
> SVcolo : Silicon Valley Colocation
> <?php
>
> /*
> Extension to PHP iCalendar for supporting publishing from Apple iCal
> Date: 11.12.2003
> Author: Dietrich Ayala
> Copyright 2003 Dietrich Ayala
>
> Description:
> This allows iCal to publish to your PHP iCalendar site *without* WebDAV support.
> This helps with commercial hosts where WebDAV is not available.
>
> Features:
> - supports publishing and deleting calendars
> - does not require WebDAV
>
> Installation:
> 1. place this file in your PHP iCalendar calendars directory (or anywhere else)
> 2. configure path to PHP iCalendar config file (below)
> 3. make sure that PHP has write access to the calendars directory (or whatever you set $calendar_path to)
> 4. set up directory security on your calendars directory
> 5. turn on publishing in your PHP iCalendar config file by setting $phpicalendar_publishing to 1.
>
> Security:
> The calendars directory should be configured to require authentication.
> This protects any private calendar data, and prevents unauthorized users
> from updating or deleting your calendar data.
>
> Three methods of HTTP authorization are supported.
>
> 1. Server-provided authentication - This can be done via any method supported by
> your webserver. There is much documentation available on the web for doing
> per-directory authentication for Apache.
>
> 2. PHP authentication against $auth_internal_username and $auth_internal_password.
>
> 2a. using mod_php it just works.
>
> 2b. If you can't configure the server for http authentication, and you are running
> PHP in CGI mode *AND* you have mod_rewrite enabled, then you should put the
> following lines in the .htaccess file in your directory:
>
> <IfModule mod_rewrite.c>
> RewriteEngine on
> RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
> </IfModule>
>
> Usage (Apple iCal):
> 1. Open iCal, select a calendar for publishing
> 2. Select "Publish" from the "Calendar" menu
> 3. Configure to your liking, and set the URL to (eg): http://example.com/path/to/publish.php
> 4. Click the "Publish" button
> 5. Some PHP versions require a '?' at the end of the URL (eg): http://localhost/~dietricha/calendar/calendars/publish.php?
>
> Usage (Sunbird Calendar):
> 1. Create a new calendar in Sunbird
> Type Remote
> Location http://example.com/path/to/publish.php/calendarname.ics
> calendarname.ics should be a unique filename and must end with .ics
> Username: either your web server username, or auth_internal_username
> Password: either your web server password, or auth_internal_password
>
> Hints:
> 1. PHP 4.3.0 or greater is required
> 2. Your version of php and apache MUST support $_SERVER['PATH_INFO']
> 3. Depending on your web server environment, you may need to set safe_mode = Off
> (this won't be necessary if you are using a wrapper like cgiwrap or suexec)
>
> Troubleshooting:
> You can turn on logging by setting the PHPICALENDAR_LOG_PUBLISHING constant to 1 below.
> This will write out a log file to the same directory as this script.
> Don't forget to turn off logging when done!!
> */
>
> // include PHP iCalendar configuration variables
> include('../config.inc.php');
>
> // set calendar path, or just use current directory...make sure there's a trailing slash
> if (isset($calendar_path) && $calendar_path != '') {
> if (substr($calendar_path, -1, 1) !='/') $calendar_path = $calendar_path.'/';
> } else {
> $calendar_path = '';
> }
> // allow/disallow publishing
>
> $phpicalendar_publishing = isset($phpicalendar_publishing) ? $phpicalendar_publishing : 0;
> define( 'PHPICALENDAR_PUBLISHING', $phpicalendar_publishing );
>
> // toggle logging
> define( 'PHPICALENDAR_LOG_PUBLISHING', 1 );
>
> // Require authentication
> if (!isset($_SERVER['REMOTE_USER'])) {
>
> // Require authentication
> if (!isset($_SERVER['HTTP_AUTHORIZATION'])) {
> list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW'])
> = explode( ':', base64_decode( substr($_SERVER['HTTP_AUTHORIZATION'], 6) ) );
> }
>
> if (!isset($_SERVER['PHP_AUTH_USER'])) {
> header('WWW-Authenticate: Basic realm="phpICalendar"');
> header('HTTP/1.0 401 Unauthorized');
> echo 'You must be authorized!';
> exit;
> } else {
> // logmsg($_SERVER['PHP_AUTH_PW'] . '|' . $_SERVER['PHP_AUTH_USER']);
> if ($_SERVER['PHP_AUTH_USER'] != $auth_internal_username || $_SERVER['PHP_AUTH_PW'] != $auth_internal_password) {
> header('WWW-Authenticate: Basic realm="phpICalendar"');
> header('HTTP/1.0 401 Unauthorized');
> echo 'You must be authorized!';
> exit;
> }
> }
> }
>
> // only allow publishing if explicitly enabled
> if(PHPICALENDAR_PUBLISHING != 1) {
> header('WWW-Authenticate: Basic realm="ERROR: Calendar Publishing is disabled on this server"');
> header('HTTP/1.0 401 Unauthorized');
> echo 'You must be authorized!';
> exit;
> }
>
> // unpublishing
> if($_SERVER['REQUEST_METHOD'] == 'DELETE')
> {
> // get calendar filename
> $calendar_file = $calendar_path.substr($_SERVER['REQUEST_URI'] , ( strrpos($_SERVER['REQUEST_URI'], '/') + 1) ) ;
>
> logmsg('received request to delete '.$calendar_file);
>
> // remove calendar file
> if(!unlink($calendar_file))
> {
> logmsg('unable to delete the calendar file');
> }
> else
> {
> logmsg('deleted');
> }
> return;
> }
>
> // publishing
> if($_SERVER['REQUEST_METHOD'] == 'PUT'){
> // get calendar data
> if($fp = fopen('php://input','r')){
> while(!@feof($fp)){
> $data .= fgets($fp,4096);
> }
>
> @fclose($fp);
> }else{
> logmsg('unable to read input data');
> }
>
> if(isset($data)){
> if (isset($_SERVER['PATH_INFO'])) {
> preg_match("/\/([\w\.\+]*).ics/i",$_SERVER['PATH_INFO'],$matches);
> $calendar_name = $matches[1];
> preg_replace( "/+/", " ", $calendar_name );
> }
>
> // If we don't have it from path info, use the supplied calendar name
> if( ! isset($calendar_name) ) {
>
> $cal_arr = explode("\n",$data);
>
> foreach($cal_arr as $k => $v){
> if(strstr($v,'X-WR-CALNAME:')){
> $arr = explode(':',$v);
> $calendar_name = trim($arr[1]);
> break;
> }
> }
> }
>
> // Remove any invalid characters from the filename
> preg_replace( "/[^\w\.\- ]/", '', $calendar_name );
>
> // If we don't have a name, assume default
> $calendar_name = isset($calendar_name) ? $calendar_name : 'default';
>
> logmsg('received request to update ' . $calendar_name);
>
> // write to file
> if($fp = fopen($calendar_path.$calendar_name.'.ics','w+')){
> fputs($fp, $data, strlen($data) );
> @fclose($fp);
> }else{
> logmsg( 'could not open file '.$calendar_path.$calendar_name.'.ics' );
> }
> }
> }
> if ($_SERVER['REQUEST_METHOD'] == 'GET') {
> if (isset($_SERVER['PATH_INFO'])) {
> preg_match("/\/([ A-Za-z0-9._]*).ics/i",$_SERVER['PATH_INFO'],$matches);
> $icsfile = $matches[1];
> // get calendar data
> if (file_exists($calendar_path . $icsfile . '.ics') &&
> is_readable($calendar_path . $icsfile . '.ics') &&
> is_file($calendar_path . $icsfile . '.ics')
> ) {
> echo file_get_contents($calendar_path . $icsfile . '.ics');
> }
> }
> }
>
> exit;
>
>
> // for logging
> function logmsg($str){
> if(defined('PHPICALENDAR_LOG_PUBLISHING') && PHPICALENDAR_LOG_PUBLISHING == 1) {
> if($fp = fopen('publish_log.txt','a+')) {
> $logline = $_SERVER['REMOTE_ADDR'] . date(' Y-m-d H:i:s ') . ${str} . "\n";
> fputs($fp, $logline, strlen($logline) );
> fclose($fp);
> }
> }
> }
> ?>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Phpicalendar-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpicalendar-devel
--
Jo Rhett
senior geek
SVcolo : Silicon Valley Colocation
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X