Bug#509864: RFP: foswiki -- The Free and Open Source Wiki
Additionally, the foswiki deb package and 106 od the Foswiki Extensions built into deb's are available from my debian repository at http://fosiki.com/Foswiki_debian so - can I get cont...@bugs to retitle 509864 ITP: foswiki -- The Free and Open Source Wiki owner 509864 svendowid...@home.org.au | olivier.ber...@it-sudparis.eu Sven -- Consulting wiki Engineer Sven Dowideit - http://fosiki.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on Olivier Berger wrote: On Sat, Dec 27, 2008 at 09:22:58AM +0100, Olivier Berger wrote: As TWiki was removed from lenny, having foswiki packaged for Debian is all the more important. Initial bits of packaging have appeared in upstream's SVN (http://svn.foswiki.org/trunk/core/tools/pkg/ - thanks Sven). I suppose it won't be long after the soon released 1.0 foswiki, that we can have a usable package, then :-) Best regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508257: Bug#508256: please remove twiki from lenny
Sadly, the upstream fix doesn't address the root cause of the url parameter problem (and we've reported to them at least one exploit that is unfixed by their patch), and I'm working on the Foswiki fork of twiki, which is addressing the security issues we know about in what I consider a more thorough way, I have not had time to do more serious work on TWiki - including the debian package. Unless someone steps in to work more actively on the packaging, I would have to agree that its better to remove TWiki from Debian at this point. Sven Florian Weimer wrote: * Dominic Hargreaves: I'm disappointed that the code execution isn't hasn't been addressed (in testing or stable) but upstream do provide a trivial patch for the version of twiki we have in Debian. If I was to NMU this (I've already applied it manually on my system) would this mitigate the need to remove twiki? We'd rather see someone testing a more complete patch (collecting fixes for all the reported problems) on a production system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508256: CVE-2008-5304: Cross-site scripting vulnerability with TWiki URLPARAM variable
This is a pretty worrying 'fix'. The Foswiki guys analysed the situation, and felt that changing URLPARAM as twiki did was not addressing the issue at all (and I agree). What they did was to change the code to default to a safe encoding, and to then allow the user to optionally request different versions of it. This still involves changing some topics though :/ Sven Olivier Berger wrote: Hi. I've had a look at this one bug, but it may not be easy to fix, I'm afraid, as we're not in sync with upstream's latest version. It seems only some of the occurences of URLPARAM need to be fixed (those inside forms POSTed, IIRC). The hard thing is to identify them. Maybe some merging between current versions in Debian, upstream's previous one and upstream's latest ? Also there's the problem of updating the installed topics files for running TWikis. Any comments much welcome. Best regards, Le mardi 09 décembre 2008 à 10:54 +, Dominic Hargreaves a écrit : Please see http://twiki.org/cgi-bin/view/Codev/SecurityAlert-CVE-2008-5304 for details of an XSS vulnerability affecting 4.1.2. Thanks, Dominic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499534: twiki: Remote code execution vulerability.
oh crepe. I thought we'd dealt with this already, but i was wrong. looking into it - 4.1.2-5 here we come. Sven -- Consulting wiki Engineer Sven Dowideit - http://fosiki.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on Moritz Muehlenhoff wrote: On Tue, Oct 07, 2008 at 02:38:31PM +0200, Nico Golde wrote: Hi Sven, * Olivier Berger [EMAIL PROTECTED] [2008-09-20 12:30]: On Sat, Sep 20, 2008 at 08:40:02AM +1000, Sven Dowideit wrote: This is _not_ a grave severity issue in the debian package, specifically because configure (as mentioned in the advisory) is locked down using apache to 1 localhost 2 an admin user that is created by the installer. ... well, at least for version in lenny (4.1.2-4), since we have fixed #485562 previously (I'm glad we did, then ;). It would be still nice if this could be fixed... even if this is not a grave issue. Swen, what's the status for Lenny? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482306: I think Olivier fixed this in a previous change to the package?
-- Consulting wiki Engineer Sven Dowideit - http://fosiki.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499534: twiki: Remote code execution vulerability.
I have uploaded an updated 4.1.2-5 with this and a few other things fixed. I've emailed Ardo asking for sponsorship, but if he's not around, would appreciate assistance :) Sven -- Consulting wiki Engineer Sven Dowideit - http://fosiki.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on Moritz Muehlenhoff wrote: On Tue, Oct 07, 2008 at 02:38:31PM +0200, Nico Golde wrote: Hi Sven, * Olivier Berger [EMAIL PROTECTED] [2008-09-20 12:30]: On Sat, Sep 20, 2008 at 08:40:02AM +1000, Sven Dowideit wrote: This is _not_ a grave severity issue in the debian package, specifically because configure (as mentioned in the advisory) is locked down using apache to 1 localhost 2 an admin user that is created by the installer. ... well, at least for version in lenny (4.1.2-4), since we have fixed #485562 previously (I'm glad we did, then ;). It would be still nice if this could be fixed... even if this is not a grave issue. Swen, what's the status for Lenny? Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499534: twiki: Remote code execution vulerability.
This is _not_ a grave severity issue in the debian package, specifically because configure (as mentioned in the advisory) is locked down using apache to 1 localhost 2 an admin user that is created by the installer. Sven Brad Krane wrote: Package: twiki Version: 1:4.0.5-9.1 Severity: grave Tags: security Justification: user security hole TWiki command execution vulnerability found in current version. US-CERT Vulnerability Note: http://www.kb.cert.org/vuls/id/362012 and TWiki Security Alert: http://twiki.org/cgi-bin/view/Codev/SecurityAlert-CVE-2008-3195 -- System Information: Debian Release: 4.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=en_CA, LC_CTYPE=en_CA (charmap=ISO-8859-1) Versions of packages twiki depends on: ii apache-common 1.3.34-4.1+etch1 support files for all Apache webse ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii libalgorithm-diff-perl 1.19.01-2a perl library for finding Longest ii libcgi-session-perl 4.14-1 Persistent session data in CGI app ii libdigest-sha1-perl 2.11-1 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/exception ha ii libhtml-parser-perl 3.55-1 A collection of modules that parse ii liblocale-maketext-lexi 0.62-1 Lexicon-handling backends for Loc ii libtext-diff-perl 0.35-2 Perform diffs on files and record ii liburi-perl 1.35-2 Manipulates and accesses URI strin ii perl [libmime-base64-pe 5.8.8-7etch3 Larry Wall's Practical Extraction ii perl-modules [libnet-pe 5.8.8-7etch3 Core Perl modules ii rcs 5.7-18 The GNU Revision Control System twiki recommends no packages. -- debconf information excluded -- Consulting wiki Engineer Sven Dowideit - http://fosiki.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482321: twiki: mod_perl suggestion useless ?
did you just seriously reply to yourself, pointing me at my own blog? :} yes, twiki does work with mod_perl, and I had the debian package try to automatically select mod_perl if it could - but everything came unstuck when some apache conditionals didn't work. usual work in progress stuff really Sven Olivier Berger wrote: On Wed, May 21, 2008 at 10:01:40PM +0200, Olivier Berger wrote: Hello. Twiki Suggests: libapache-mod-perl, libapache2-mod-perl2, ...; however the perl scripts are executed as CGI AFAICT. Would twiki work with mod_perl ? Anyway, that's not consistent, IMHO. Mys 2 cents, Best regards. The following may be helpful : http://home.org.au/cgi-bin/view/Blog/BlogEntry2007x04x03x01x23 I didn't test it myself though. Hope this helps, Best regards, -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: emergency upload request for TWiki
ah, thanks :) do I need to find and contact (and bribe with beer?) someone to 'convince release-manager'? Sven Vincent Bernat wrote: OoO En ce début d'après-midi ensoleillé du dimanche 24 août 2008, vers 15:33, Sven Dowideit [EMAIL PROTECTED] disait : I've finally placed a new twiki 4.1.2-4 deb at http://distributedinformation.com/TWikiDebian/twiki_4.1.2-4_i386.changes I have put the session files into /var/lib/twiki/tmp and am using TWiki's built in settings to auto remove session files after 6 hours. Could someone please upload it for me so it can go into Lenny? Hi Sven! There are a lot of lintian warnings that you should be able to correct for future releases. I have uploaded the current version to let it go into lenny. I hope that you will be able to convince release-manager to let go those changes. -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: emergency upload request for TWiki
Vincent, and DD's I've finally placed a new twiki 4.1.2-4 deb at http://distributedinformation.com/TWikiDebian/twiki_4.1.2-4_i386.changes I have put the session files into /var/lib/twiki/tmp and am using TWiki's built in settings to auto remove session files after 6 hours. Could someone please upload it for me so it can go into Lenny? Sven Vincent Bernat wrote: OoO Pendant le temps de midi du samedi 16 août 2008, vers 12:36, Sven Dowideit [EMAIL PROTECTED] disait : frustratingly, I'm not a DD and Worse. I have an emergency update to TWiki for a security issue that needs fixing for Lenny, but I have no DD to help me upload it Anyone here willing to do a quick package upload of TWiki in the next day? Hi Sven! I would be happy to upload your fix but I disagree with it. As pointed by Olivier at the end of the bug report, /tmp can be flushed at boot or by some cronjobs. Therefore, you cannot ensure that the twiki directory still exists when twiki will be running. I cannot give an universal solution, but in Roundcube, we use /var/lib/roundcube/temp and we provide a cron job that will clean it every m days where m can be set by the user in /etc/default/roundcube (and I just noticed that this is broken... will upload a fix). This way, we don't fill up /var but we don't rely on anything in /tmp. Moreover, we don't have to handle a complex script in postinst to circumvent symlinks attacks. The problem with webapps is that we don't have a clear policy of what to do. You can just look at other packages, like phpmyadmin, mediawiki, etc. Each attempt to establish a webapps policy seems to be aborted. -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: About (TWiki/web apps) sessions save dir - Was: Re: RFS: Second try for twiki-ldapcontrib, new upstream version - Re: RFS: twiki-ldapcontrib - LDAP services for TWiki
Having slept on it, I agree with Vincent and Dmitry. I think there is no sane way to have a secure session dir for cgi apps that might at any time need to be recreated with a unique name... basically, imagine what happens when you have a heavily loaded server, each of 100s of cgi scripts realising that the session dir has gone, and they all create a unique new one, and try to update the cfg file!!! seriously bad news. I will re-do the twiki package to rely on /var/run/twiki (or /var/lib/twiki/tmp if someone here suggests so) and a cronjob. Post Lenny, I think is is desperatly important for DD's to get a Secure cgi session _file_ policy created - and I suspect, some support systems to ensure that it won't cause the server issues such as filling up /var, preventing logging (the reason that I originally was asked to move it out of /var/lib/twiki). Could someone please give me an idea of how long i have before it is too late to fix this for lenny? Sven Olivier Berger wrote: Hi Vincent. Le samedi 16 août 2008 à 13:26 +0200, Vincent Bernat a écrit : I would be happy to upload your fix but I disagree with it. As pointed by Olivier at the end of the bug report, /tmp can be flushed at boot or by some cronjobs. Therefore, you cannot ensure that the twiki directory still exists when twiki will be running. I cannot give an universal solution, but in Roundcube, we use /var/lib/roundcube/temp and we provide a cron job that will clean it every m days where m can be set by the user in /etc/default/roundcube (and I just noticed that this is broken... will upload a fix). This way, we don't fill up /var but we don't rely on anything in /tmp. Moreover, we don't have to handle a complex script in postinst to circumvent symlinks attacks. The problem with webapps is that we don't have a clear policy of what to do. You can just look at other packages, like phpmyadmin, mediawiki, etc. Each attempt to establish a webapps policy seems to be aborted. That's why I asked for advice on debian-devel@ with no success :( http://lists.debian.org/debian-devel/2008/08/msg00340.html Feel free to comment anyway ;) Best regards, -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
similar to the change I have just coded and tested :) thanks Dmitry E. Oboukhov wrote: tags 494648 patch thanks Hi, Sven see my patch, please -- . ''`. Dmitry E. Oboukhov : :’ : [EMAIL PROTECTED] `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: emergency upload of TWiki package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ardo, Christian .. I've just put an updated version of the twiki package at http://distributedinformation.com/TWikiDebian/ that fixes both the security flaw Dmitry found, and a few other bad oddities. Could one of you by any chance take a look at it (and upload) for me? Cheers Sven - - twiki (1:4.1.2-4) unstable; urgency=emergency . * squash softlink exploit on session directory (Closes: #494648) * related issue with passthrough files (Closes: #468159) * fix dependancys on apache* rather than apache*-common (Closes: #482285) * remove TWikiGuest user with hardcoded password from htpassword. * Build instructions moved from section -arch to -indep (closes lintian warning). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkij9N0ACgkQPAwzu0QrW+mGQQCdGRs2dOEYBMUwe3a2u295ce1R YiUAniEIg8OpeJ6YiOcOLHJh1S6HeBwq =dxUO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: emergency upload of TWiki package
I really dunno. I recal having an explicit ack to the NMU's a few years ago, and being told to remove it. The longer I do this debian stuff, the more I wish lintian were more helpful, and more retentive. IF is it policy to ack MNU's in the next changelog, lintian should probly complain bitterly :) Sven Olivier Berger wrote: Hi. Haven't had a chance to look at the updated package yet (will try today), but I think it may be better to acknowledge previous NMUs explicitely in the changelog. Hope this helps, Best regards, Le jeudi 14 août 2008 à 19:03 +1000, Sven Dowideit a écrit : Ardo, Christian .. I've just put an updated version of the twiki package at http://distributedinformation.com/TWikiDebian/ that fixes both the security flaw Dmitry found, and a few other bad oddities. Could one of you by any chance take a look at it (and upload) for me? Cheers Sven - - twiki (1:4.1.2-4) unstable; urgency=emergency . * squash softlink exploit on session directory (Closes: #494648) * related issue with passthrough files (Closes: #468159) * fix dependancys on apache* rather than apache*-common (Closes: #482285) * remove TWikiGuest user with hardcoded password from htpassword. * Build instructions moved from section -arch to -indep (closes lintian warning). -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
Nico, /var/run - I'll keep that in mind for post lenny - I was really hoping that debian had a place for this sort of session data, but didn't manage to get there - thanks :) I'm hoping for the next release that I can move everything into /var/twiki (rather than scattered around the fs, including pollution the perl lib dirs) so that TWiki people stop being totally confused by the setup :/ Sven Nico Golde wrote: Hi Sven, * Sven Dowideit [EMAIL PROTECTED] [2008-08-13 11:05]: I'd need a second opinion on this report please. My recollection was that we squashed this in Bug#444982 If not, is there any chance that automated tool users are at least required to help out with a bit more information that the alarmist text below? I will have to assume that this report is indeed incorrect unless I hear otherwise. Yes it looks indeed like this bug is invalid but this would be also hard to spot in a script. There might be still a better solution than storing these files in /tmp so people might not report this again in the future. What about /var/run? Kind regards Nico -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
Steve, yes but your information is outdated. (although i'm embarrassed that we didn't also resolve it in the etch version :/) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444982 Found in versions 4.1.2-1, twiki/1:4.1.2-2 Fixed in version twiki/1:4.1.2-3 and so, it seems to me that we're ok for the version that is going into lenny - I'll close it as soon as i can find the docco for howto do that :/ Sven Steve Kemp wrote: On Wed Aug 13, 2008 at 11:31:54 +1000, Sven Dowideit wrote: I will have to assume that this report is indeed incorrect unless I hear otherwise. On my Debian Etch system: [EMAIL PROTECTED]:~$ apt-get source twiki Reading package lists... Done Building dependency tree... Done Need to get 4304kB of source archives. Get: 1 http://mirror.bytemark.co.uk etch/main twiki 1:4.0.5-9.1 (dsc) [639B] Get: 2 http://mirror.bytemark.co.uk etch/main twiki 1:4.0.5-9.1 (tar) [4264kB] Get: 3 http://mirror.bytemark.co.uk etch/main twiki 1:4.0.5-9.1 (diff) [39.3kB] Fetched 4304kB in 7s (546kB/s) gpg: Signature made Wed 21 Feb 2007 06:51:24 GMT using DSA key ID C0143D2D gpg: Can't check signature: public key not found dpkg-source: extracting twiki in twiki-4.0.5 dpkg-source: unpacking twiki_4.0.5.orig.tar.gz dpkg-source: applying ./twiki_4.0.5-9.1.diff.gz [EMAIL PROTECTED]:~$ cd twiki-4.0.5/ [EMAIL PROTECTED]:~/twiki-4.0.5$ grep /tmp/twiki debian/postinst if [ ! -e /tmp/twiki ]; then mkdir /tmp/twiki chmod 777 /tmp/twiki chown $TWIKI_OWNER.www-data /tmp/twiki [EMAIL PROTECTED]:~/twiki-4.0.5$ So : 1. If /tmp/twiki doesn't exist it is made as a directory. 2. If it does exist its permissions are changed - unconditionally Let me exploit it: [EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ ln -s /etc/shadow /tmp/twiki [EMAIL PROTECTED]:~$ sudo apt-get install twiki Password: Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: libalgorithm-diff-perl liblocale-maketext-lexicon-perl libtext-diff-perl rcs Suggested packages: ... ... Setting up libtext-diff-perl (0.35-2) ... Setting up rcs (5.7-18) ... Setting up twiki (4.0.5-9.1) ... Adding password for user TWikiGuest Reloading web server config...3224 Now what happened? Nothing. The directory /tmp/twiki was created and my symlink wasn't touched. So we look safe. But I'm not convinced. I know that I can coerce it into working: [EMAIL PROTECTED]:~$ sudo rm -rf /tmp/twiki [EMAIL PROTECTED]:~$ ln -s /etc/shadow /tmp/twiki [EMAIL PROTECTED]:~$ sudo /var/lib/dpkg/info/twiki.postinst configure Reloading web server config...3224 . [EMAIL PROTECTED]:~$ ls -l /etc/shadow -rwxrwxrwx 1 www-data www-data 1093 2008-08-13 10:35 /etc/shadow I guess the difference is relating to the presence, or not, of /var/lib/twiki/data ? Looks like merely installing the package wouldn't trigger this, but an upgrade might. Or something like that ! Steve -- -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
na, sorry, twiki dumps session data into /tmp/twiki the /var vs /usr thing is a separate thing thta non-DD's get frustrated with - basically, most people expect twiki to be laid out in the same way as it is on non-debian system - everything under one twiki dir. Debian packaging policy confuses the hell out of them. Nico Golde wrote: Hi Olivier, * Olivier Berger [EMAIL PROTECTED] [2008-08-13 12:53]: Le mercredi 13 août 2008 à 20:06 +1000, Sven Dowideit a écrit : [...] I'm hoping for the next release that I can move everything into /var/twiki (rather than scattered around the fs, including pollution the perl lib dirs) so that TWiki people stop being totally confused by the setup :/ Hmmm... It seems to me it wouldn't be a good idea. See http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs and http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html for reference. I guess code should be in /usr/ and not in /var/ right ? twiki dumps code in this tmpdir? Cheers Nico -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
Yes, I would suggest that there is a need for more detailed web apps policies - not just for where session files should be placed safely, but also things like safe and consistent ways to configure the webservers (apache1 vs apache2 are (or were last i looked) already a pain), and similarly for module support - like turning on mod_rewrite on the different systems. the best irony of this bug, is : I've implemented Joey's suggestion of 1777 O_EXCL - mostly the files in tmp are written by CGI::Session, that takes care of things. I also moved the 1777 tmp dir back to /tmp/twiki, as per Nico's point wrt to filling /var Sven Olivier Berger wrote: Le mercredi 13 août 2008 à 20:06 +1000, Sven Dowideit a écrit : Nico, /var/run - I'll keep that in mind for post lenny - I was really hoping that debian had a place for this sort of session data, but didn't manage to get there - thanks :) Maybe there is a web apps policy to be determined here (unless it exists alread ?) For instance, when considering recent issues with session files in phpgroupware, I noticed that with php5, by default sessions may be saved in /var/lib/php5/. But as we needed some kind of admin management of sessions of users (like killing them) it led us to have them (back) into /var/lib/phpgroupware/sessions/. I guess I've asked for some policy or guidelines but got no answer. I'm hoping for the next release that I can move everything into /var/twiki (rather than scattered around the fs, including pollution the perl lib dirs) so that TWiki people stop being totally confused by the setup :/ Hmmm... It seems to me it wouldn't be a good idea. See http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs and http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html for reference. I guess code should be in /usr/ and not in /var/ right ? I guess that current dir layout is mostly good, as there are proper symlinks in /var/lib/twiki (bin, lib, data, pub, etc.). Once you're looking for something starting from /var/lib/twiki, you should find it (for TWiki folks). Still, that /usr/share/perl5/TWiki* may not be desirable, yes. Bt I'm pretty sure the configuration allows some curstomization of the perl path. Still I don't know which path would be best. Maybe something like /usr/lib/twiki/ ? Why change something that works ? ;) My 2 cents. Best regards, -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
no, its got nothing to do with /var/lib/twiki/data etc, its the location for session data - produced by CGI::Session etc. Olivier Berger wrote: Le mercredi 13 août 2008 à 11:12 +0100, Steve Kemp a écrit : On Wed Aug 13, 2008 at 11:31:54 +1000, Sven Dowideit wrote: I know that I can coerce it into working: [EMAIL PROTECTED]:~$ sudo rm -rf /tmp/twiki [EMAIL PROTECTED]:~$ ln -s /etc/shadow /tmp/twiki [EMAIL PROTECTED]:~$ sudo /var/lib/dpkg/info/twiki.postinst configure Reloading web server config...3224 . [EMAIL PROTECTED]:~$ ls -l /etc/shadow -rwxrwxrwx 1 www-data www-data 1093 2008-08-13 10:35 /etc/shadow I guess the difference is relating to the presence, or not, of /var/lib/twiki/data ? Looks like merely installing the package wouldn't trigger this, but an upgrade might. Or something like that ! And note that it may also be the same on a second install too, if after a first install, and a first removal, but which may have left over stuff in /var/lib/twiki/data ... which is not necessarily automatically purged on removal :-/ Just my 2 cents, -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner - http://wikiring.com Public key - http://pgp.mit.edu:11371/pks/lookup?search=Sven+Dowideitop=indexexact=on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
so Dmitry,
if you were trying to actually help get this fixed, I presume you would
have suggested that I just patch the code to
rm /tmp/twiki
and then create it?
or what are you actually suggesting?
Sven
Dmitry E. Oboukhov wrote:
Where?
$curl
http://ftp.nl.debian.org/debian/pool/main/t/twiki/twiki_4.1.2-3.2.diff.gz
2/dev/null|gunzip|grep -A 219 '^[+]\{3\}.*postinst'|grep '/tmp/'
+ #put into /tmp/twiki so that the open dir can't be used by others to
fill up /var, thus crashing all logging
+ if [ ! -e /tmp/twiki ]; then
+ mkdir /tmp/twiki
+ chmod 1777 /tmp/twiki
+ chown $TWIKI_OWNER.www-data /tmp/twiki
http://packages.qa.debian.org/t/twiki.html
Stable 1:4.0.5-9.1
Testing 1:4.1.2-3.2
Unstable 1:4.1.2-3.2
for etch:
$ curl
http://ftp.nl.debian.org/debian/pool/main/t/twiki/twiki_4.0.5-9.1.diff.gz
2/dev/null |gunzip|grep -A 219 '^[+]\{3\}.*postinst'|grep '/tmp/'
+ if [ ! -e /tmp/twiki ]; then
+ mkdir /tmp/twiki
+ chmod 777 /tmp/twiki
+ chown $TWIKI_OWNER.www-data /tmp/twiki
SK c. Except in Etch.
and lenny and sid
SK Steve
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
these are _WEB_ session files.
there are no user directories.
Dmitry E. Oboukhov wrote:
SD so Dmitry,
SD if you were trying to actually help get this fixed, I presume you would
SD have suggested that I just patch the code to
SD rm /tmp/twiki
SD and then create it?
SD or what are you actually suggesting?
SD Sven
At my oppinion You can oblige user to create this temp-dir
in his directories and use user copy of LocalSite.cfg instead system
config ($TWiki::cfg{RCS}{WorkAreaDir}).
hmm
--
... mpd playing: U.D.O. - Private Eye
. ''`. Dmitry E. Oboukhov
: :’ : [EMAIL PROTECTED]
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
So are you suggesting that I instead fill up /tmp directly with thousands of cgisess_123412 files? because the location that those files go into needs to be predictable - so that each cgi script goes to the same place. Julien Cristau wrote: On Wed, Aug 13, 2008 at 23:24:47 +1000, Sven Dowideit wrote: so Dmitry, if you were trying to actually help get this fixed, I presume you would have suggested that I just patch the code to rm /tmp/twiki and then create it? or what are you actually suggesting? No. Don't touch/use predictable file names in /tmp. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
No, I was told by Nico or Joey that web apps should not be filling up
the /var filesystem with session files.
this is apparently also _not_ a solution.
/tmp was determined in October 2007 as the best place
Dmitry E. Oboukhov wrote:
On 00:17 Thu 14 Aug , Sven Dowideit wrote:
SD these are _WEB_ session files.
SD there are no user directories.
then it must have
user:group == www-data:www-data
and attributes = 0700 or 0770 or 0750
and be placed to /var/???/twiki
SD Dmitry E. Oboukhov wrote:
SD so Dmitry,
SD
SD if you were trying to actually help get this fixed, I presume you would
SD have suggested that I just patch the code to
SD
SD rm /tmp/twiki
SD and then create it?
SD
SD or what are you actually suggesting?
SD
SD Sven
SD
SD At my oppinion You can oblige user to create this temp-dir
SD in his directories and use user copy of LocalSite.cfg instead system
SD config ($TWiki::cfg{RCS}{WorkAreaDir}).
SD
SD hmm
SD
SD --
SD ... mpd playing: U.D.O. - Private Eye
SD
SD . ''`. Dmitry E. Oboukhov
SD : :’ : [EMAIL PROTECTED]
SD `. `~’ GPGKey: 1024D / F8E26537 2006-11-21
SD `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
--
... mpd is off
. ''`. Dmitry E. Oboukhov
: :’ : [EMAIL PROTECTED]
`. `~’ GPGKey: 1024D / F8E26537 2006-11-21
`- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
Yes, you should not share CGI::Session files, it does lead to leakage, and really odd side effects. Olivier Berger wrote: Le mercredi 13 août 2008 à 16:19 +0200, Julien Cristau a écrit : On Wed, Aug 13, 2008 at 23:24:47 +1000, Sven Dowideit wrote: so Dmitry, if you were trying to actually help get this fixed, I presume you would have suggested that I just patch the code to rm /tmp/twiki and then create it? or what are you actually suggesting? No. Don't touch/use predictable file names in /tmp. Which leads us again to something like /var/run/twiki/session/ or /var/lib/twiki/tmp/session/ or some other custom path, with some garbage collection (cronjob ?) and all the fuss ? Maybe there are best practice use of CGI::Session somewhere ? ... not to mention other uses of the other files created in /tmp/twiki at the moment... but the most critical seems to be the dir creation in the postinst. Or maybe simply not create a separate dir for session files and use plain clear /tmp for CGI::Session files ? Unless that leads to potential information leaks ? Follow-up to : http://lists.debian.org/debian-devel/2008/08/msg00340.html ? My 2 cents, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
Dmitry E. Oboukhov wrote: On 00:38 Thu 14 Aug , Sven Dowideit wrote: SD No, I was told by Nico or Joey that web apps should not be filling up SD the /var filesystem with session files. SD this is apparently also _not_ a solution. SD /tmp was determined in October 2007 as the best place Ok, Yoy can do it (in your postinst): twiki_session_dir=`mktemp -d /tmp/twiki.XX` chown www-data:www-data $twiki_session_dir # or chown $TWIKI_OWNER:www-data chmod 0750 $twiki_session_dir # or chmod 1770 if $TWIKI_OWNER != www-data perl -pi -e s/(TempfileDir).*/$1} = '$twiki_session_dir'; \ /etc/twiki/LocalSite.cfg attributes must be 0750 or 0770 or 0700 if owner==www-data or 1770 if owner != www-data ($TWIKI_OWNER) and then on upgrade, create another one because the user selected to overwrite the cfg, and so on - sounds like its less of a solution than to use a predictable dir, with a more appropriate attempt to make sure its safe. it worries me that you appear to be contradicting the permissions I was required to set up for #444982 - I'm not quite sure who's advice should get priority - Joey's or yours. Perhaps I should set up a google fight. Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
how would this would be different from ? Debian Bug report logs - #468159 twiki: Redirect after Template Login failes Olivier Berger wrote: On Wed, Aug 13, 2008 at 10:12:29PM +1000, Sven Dowideit wrote: the best irony of this bug, is : I've implemented Joey's suggestion of 1777 O_EXCL - mostly the files in tmp are written by CGI::Session, that takes care of things. I also moved the 1777 tmp dir back to /tmp/twiki, as per Nico's point wrt to filling /var By coincidence (testing authentication through CAS servers for TWiki, and tracing what happens in TemplateLogin), I happend to run into that O_EXCL permission on passthru files (dunno what they are, btw), and notice that apparently #444982 wasn't fixed the right way it seems. See more details in newly filed #494993. Sad irony ;-) Best regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Guys, I'd need a second opinion on this report please. My recollection was that we squashed this in Bug#444982 If not, is there any chance that automated tool users are at least required to help out with a bit more information that the alarmist text below? I will have to assume that this report is indeed incorrect unless I hear otherwise. Sven Dmitry E. Oboukhov wrote: Package: twiki Severity: grave Tags: security This message about the error concerns a few packages at once. I've tested all the packages on my Debian mirror. (post|pre)(inst|rm) and config scripts were tested. In some packages I've discovered scripts with errors which may be used by a user for damaging important system files. For example if a script uses in its work a temp file which is created in /tmp directory, then every user can create symlink with the same name in this directory in order to destroy or rewrite somesystem file. I set Severity into grave for this bug. The tableof discovered problems is below. +--+-+-- |package | script | file for attack +--+-+-- | mplayer-1.0~rc2 | config | /tmp/HACK (pipe) | | | | nws-2.13 | postinst | /tmp/nws.debug (cp) | | | | ppp-2.4.4rel | postinst | /tmp/probe-finished (rm -f, pipe) | | postinst | /tmp/ppp-errors (rm -f, pipe) | ppp-udeb | /etc/ppp/ip-up | /tmp/resolv.conf.tmp (cp) | | | | twiki-4.1.2 | postinst | /tmp/twiki (chmod 1777, chown) +--+-+-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiiOYoACgkQPAwzu0QrW+nHKACgt+Yd/wMsLK+wvBAgA1qEww4g 1hoAnRexz3Up2jQeJzhamJ0k0Nh4sf2H =rxz+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494648: The possibility of attack with the help of symlinks in some Debian packages
ah, good find. Ardo and Christian, If I make an update to the 4.1.2 package, fixing this, and a couple of other issues that I've been told about in the next 48 days, would one of you be willing to upload it for me so it gets into Lenny? Sven Dmitry E. Oboukhov wrote: Package: twiki Severity: grave Tags: security This message about the error concerns a few packages at once. I've tested all the packages on my Debian mirror. (post|pre)(inst|rm) and config scripts were tested. In some packages I've discovered scripts with errors which may be used by a user for damaging important system files. For example if a script uses in its work a temp file which is created in /tmp directory, then every user can create symlink with the same name in this directory in order to destroy or rewrite somesystem file. I set Severity into grave for this bug. The tableof discovered problems is below. +--+-+-- |package | script | file for attack +--+-+-- | mplayer-1.0~rc2 | config | /tmp/HACK (pipe) | | | | nws-2.13 | postinst | /tmp/nws.debug (cp) | | | | ppp-2.4.4rel | postinst | /tmp/probe-finished (rm -f, pipe) | | postinst | /tmp/ppp-errors (rm -f, pipe) | ppp-udeb | /etc/ppp/ip-up | /tmp/resolv.conf.tmp (cp) | | | | twiki-4.1.2 | postinst | /tmp/twiki (chmod 1777, chown) +--+-+-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485562: twiki: configure script access badly protected
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I was hoping to have time for this today, but it seems not to be.
I would suggest using 'TWiki Configure User Password' and setting the
configure save pwd to the same thing. (and making the username for it
'admin')
That way it will not need to change for the 4.2.x package, where there
is an internal admin user, whose password is the same as the configure
save password, and will also be used to authenticate to get to the
configure script.
I might still hammer out a 4.2.0 package tomorrow, but no breath holding
please.
Sven
Justin B Rye wrote:
Olivier Berger wrote:
*Should be apache in all three.*
By apache user, I mean something which relates to Require user in the
apache.conf section of the 'configure' script... of course, this assumes
that it's running apache and no other web server ;)
In any case, that's meant to differenciate from TWiki users, which are
managed inside twiki.
I'm still not quite convinced by the expression apache user, but I
can't decide what alternative I'd suggest.
The trouble with apache user is that it might mean the local
system's www-data, or maybe the owner of the computer, rather than
a browser-user authenticated via mod_auth_basic...
_Description: User allowed access to 'configure' script
Please enter the name of the user who will be allowed
to run the configure script at ${site}/cgi-bin/configure.
_Description: Password for ${configuser}:
Please enter the password of the user who will be allowed
to run the configure script at ${site}/cgi-bin/configure.
Where is... HTTP? authenticated? htpasswd?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIZfClPAwzu0QrW+kRAqOdAKCxrPpAFp0LpvZW5esxx6t3uT3enACfcwrT
fWpvioHo5QOeWTn2qtvFz9s=
=RzJ1
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485562: twiki: configure script access badly protected
odd, I'm under the impression that I did respond, and indicated taht I don't see it as a major issue. no-one on the security team suggested it was either, leading me to believe that we had a consensus. Sven Olivier Berger wrote: Package: twiki Version: 1:4.1.2-3.1 Severity: grave Tags: security Justification: user security hole In current state of the Debian package, if nothing is changed manually to the default setup configured by the package, then TWiki's configure script is accessible easily to unauthorized people, thus exposing (incl. changing it) the configuration of TWiki.For instance, it would be possible to change settings which may compromize the wiki's functionning (including commands executed as www-data). Full details have already be notified (by me) to the maintainer and the security team through direct emails. A proposed patch to address this issue was also provided through direct emails too. Unfortunately, maintainer seems too busy to be able to acknowledge all that at the moment. So I'm filing this ticket so that appropriate mesures be taken regarding the possible inclusion of such a security risk in coming stable release. Hope this helps, Best regards. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-openvz-24-004.1d1-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages twiki depends on: ii apache2.2-common 2.2.8-4 Next generation, scalable, extenda ii debconf [debconf-2.0] 1.5.22Debian configuration management sy pn libalgorithm-diff-perl none(no description available) ii libcgi-session-perl4.30-1Persistent session data in CGI app ii libdigest-sha1-perl2.11-2+b1 NIST SHA-1 message digest algorith ii liberror-perl 0.17-1Perl module for error/exception ha ii libhtml-parser-perl3.56-1+b1 A collection of modules that parse pn liblocale-maketext-lexicon none(no description available) pn libtext-diff-perl none(no description available) ii liburi-perl1.35.dfsg.1-1 Manipulates and accesses URI strin ii perl [libmime-base64-perl] 5.10.0-10 Larry Wall's Practical Extraction ii perl-modules [libnet-perl] 5.10.0-10 Core Perl modules ii rcs5.7-23The GNU Revision Control System twiki recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485562: twiki: configure script access badly protected
Also, the patch was found, by you to be defective. So I was expecting to see another round. Olivier Berger wrote: Package: twiki Version: 1:4.1.2-3.1 Severity: grave Tags: security Justification: user security hole In current state of the Debian package, if nothing is changed manually to the default setup configured by the package, then TWiki's configure script is accessible easily to unauthorized people, thus exposing (incl. changing it) the configuration of TWiki.For instance, it would be possible to change settings which may compromize the wiki's functionning (including commands executed as www-data). Full details have already be notified (by me) to the maintainer and the security team through direct emails. A proposed patch to address this issue was also provided through direct emails too. Unfortunately, maintainer seems too busy to be able to acknowledge all that at the moment. So I'm filing this ticket so that appropriate mesures be taken regarding the possible inclusion of such a security risk in coming stable release. Hope this helps, Best regards. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-openvz-24-004.1d1-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages twiki depends on: ii apache2.2-common 2.2.8-4 Next generation, scalable, extenda ii debconf [debconf-2.0] 1.5.22Debian configuration management sy pn libalgorithm-diff-perl none(no description available) ii libcgi-session-perl4.30-1Persistent session data in CGI app ii libdigest-sha1-perl2.11-2+b1 NIST SHA-1 message digest algorith ii liberror-perl 0.17-1Perl module for error/exception ha ii libhtml-parser-perl3.56-1+b1 A collection of modules that parse pn liblocale-maketext-lexicon none(no description available) pn libtext-diff-perl none(no description available) ii liburi-perl1.35.dfsg.1-1 Manipulates and accesses URI strin ii perl [libmime-base64-perl] 5.10.0-10 Larry Wall's Practical Extraction ii perl-modules [libnet-perl] 5.10.0-10 Core Perl modules ii rcs5.7-23The GNU Revision Control System twiki recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485562: twiki: configure script access badly protected
I still contend that Allow from 127.0.0.1 does _not_ constitute open to anyone on the internet. While hard coding TWikiGuest with a password of guest is not in any sense a good thing, from what I've noticed of other debian packages (and the fact that this was the case when I inherited the package) make me feel that its _not_ an issue that demands everyone to drop everything. Satisfy Any is not a better solution, as it opens configure up to an even bigger group of users - anyone that has registered on the TWiki. That said, I was (and am) expecting that as Olivier has such a strong interest, that he will be fixing the issues he found in his own patch, so that the package can become better. In fact, I'm hoping he'll help finish the 4.2.x TWiki package that i started work on last time i had the time to look. Sven Olivier Berger wrote: Le mardi 10 juin 2008 à 17:39 +1000, Sven Dowideit a écrit : odd, I'm under the impression that I did respond, and indicated taht I don't see it as a major issue. OK, here I strongly disagree. You say you don't see as a major issue that anyone on the Internet can access and change a TWiki instance's configuration as user TWikiGuest/guest, as long as the server is on the Net (unless the admin has manually tweaked the apache config) ?!? Maybe someone will provide more insightful comments, now the issue is public ? It may not be major... but still, it's quite an issue... right ? Why is there any such Apache config, whereas limiting to local user's access for configure should be a *minimum* provision for confidentiality, at least, for instance (even though that's not enough IMHO)... Leaving the current apache config as such is nonsense for default installation (in particular the Satisfy Any), IMHO. What do you propose to address it ? Feel free to downgrade the severity or otherwise change the ticket's attributes. But I'm sure I would restore it as currently is. no-one on the security team suggested it was either, leading me to believe that we had a consensus. No one explicitely said yes or no, AFAICT... this is far from consensus (or I missed some emails). All I could read from someone from security team was : From: Florian Weimer [EMAIL PROTECTED] To: Olivier Berger [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Sven Dowideit [EMAIL PROTECTED], Sven Dowideit [EMAIL PROTECTED] Subjet: Re: Security issue for Twiki's configure script execution possible by default Date: Wed, 28 May 2008 20:29:36 +0200 * Olivier Berger: I may be wrong, but I don't think I got an ACK (even to say no time to read yet) that this message was received. I had hoped the maintainer chimed in. This problem seems to be known by the maintainer, as discussed in http://twiki.org/cgi-bin/view/Codev/TWikiOnDebian (comments dated nov. 2007), AFAICT... Maybe he even prepared something in order to address this problem, which for some reason was not uploaded to Debian yet, as the packaging changelog seems to indicate : http://svn.twiki.org/svn/twiki/trunk/core/tools/pkg/debian/changelog : * change configure to use any valid-user - TWikiGuest is silly Sven, can you comment on this? Is anybody from the security team familiar with Apache ACLs and can propose a fix? Then no more, the rest was between you and me. They primarily asked for your opinion... then nothing more, as I suppose they were probably too busy already on other problems. They didn't respond again when you finally responded... (which leaves us in doubt that anyone in the security team would be familiar with Apache ACLs ;-)). I guessed you were comforted in your opinion by their lack of reaction, which is yet no indication that they would agree. Sven I initially choosed not to provide more details in the report in the BTS about the problem, hoping that you agreed it was problematic, and would be willing to welcome help. But it looks like we got some misunderstanding here. Too bad I'm forced to expose more details, as there doesn't seem to be consensus (maybe a problem with communication through email which renders things more difficult ?), and the only way out will be discussing it in details and in public I think. I proposed a NMU patch (maybe not perfect, but much less worse, IMHO than current state of things), and also a bit later warned you there would be a problem. You added : Also, the patch was found, by you to be defective. So I was expecting to see another round. ... as I explained, it would only need some slight reorganization of the postinst code to separate the configure and reconfigure cases in the code flow (which would be easy in principle for the maintainer would he acknowledge the NMU, for instance ?) I expect from an active maintainer that he/she's capable of improving the proposed patches sent by others, instead of going idle until the perfect patch is provided. I know you may think I'm aggressive here
Bug#464671: twiki: adding a ')' at the end of topic in URL handled with unhandled exception
is this a bug in the debian pakage? If it is a general twiki bug, could you report it in the upstream bug tracking system?? http://develop.twiki.org. Cheers Sven Olivier Berger wrote: Package: twiki Version: 1:4.0.5-9.1 Severity: normal Whenever accessing a topic (view) with a malformed URL including a trailing ')' causes anhandled exception in regesp parsing. Example : https://myserver/cgi-bin/twiki/view/Contrib2/Private/DepotContrib) Results in : Software error: Unmatched ) in regex; marked by -- HERE in m//Contrib2/Private/DepotContrib) -- HERE $/ at (eval 19) line 7, DATA line 225. It would much better it a proper error message from TWiki was be displayed instead of this perl error. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages twiki depends on: ii apache2.2-common 2.2.3-4+etch3 Next generation, scalable, extenda ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libalgorithm-diff-perl 1.19.01-2 a perl library for finding Longest ii libcgi-session-perl4.14-1Persistent session data in CGI app ii libdigest-sha1-perl2.11-1NIST SHA-1 message digest algorith ii liberror-perl 0.15-8Perl module for error/exception ha ii libhtml-parser-perl3.55-1A collection of modules that parse ii liblocale-maketext-lexicon 0.62-1Lexicon-handling backends for Loc ii libtext-diff-perl 0.35-2Perform diffs on files and record ii liburi-perl1.35-2Manipulates and accesses URI strin ii perl [libmime-base64-perl] 5.8.8-7etch1 Larry Wall's Practical Extraction ii perl-modules [libnet-perl] 5.8.8-7etch1 Core Perl modules ii rcs5.7-18The GNU Revision Control System twiki recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
righto, I've uploaded a new version to http://distributedinformation.com/TWikiDebian/ (twiki_4.1.2-3_all.deb) * secure /var/www/twiki/pub/_work_areas (Closes: #444982) CVE-2007-5193 * session files in /tmp/twiki, and add O_EXCL to files that go there * updated Vietnamese translation (Closes: #426850) * don't modify files that are not installed (Closes: #98) I've implemented Joey's suggestion of 1777 O_EXCL - mostly the files in tmp are written by CGI::Session, that takes care of things. I also moved the 1777 tmp dir back to /tmp/twiki, as per Nico's point wrt to filling /var and fixed a few other bitzers I've reported the issue upstream so we can look at doing a more lasting change for the next release. Sven On Fri, 2007-10-26 at 16:57 +1000, Sven Dowideit wrote: ok, I'll implement this on the w/e, and push it into the upcoming 4.2 release. Thankyou Joey, as usual you've helped us unsafe bumbles again. Sven On Tue, 2007-10-23 at 20:00 -0400, Joey Hess wrote: Sven Dowideit wrote: neat summary Joey :) The reason that I made it world writeable, is that twiki cgi's can be run from the command line by anyone, and in doing so, create a session file. This is used by cronjobs, and so that users can script additions to topics etc. Makeing the temporary directory mode 1777 would not prevent that, but would prevent users from deleting and replacing twiki temp files. That and making the opens use O_EXCL, would cover the security issues I mentioned. -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
ok, I'll implement this on the w/e, and push it into the upcoming 4.2 release. Thankyou Joey, as usual you've helped us unsafe bumbles again. Sven On Tue, 2007-10-23 at 20:00 -0400, Joey Hess wrote: Sven Dowideit wrote: neat summary Joey :) The reason that I made it world writeable, is that twiki cgi's can be run from the command line by anyone, and in doing so, create a session file. This is used by cronjobs, and so that users can script additions to topics etc. Makeing the temporary directory mode 1777 would not prevent that, but would prevent users from deleting and replacing twiki temp files. That and making the opens use O_EXCL, would cover the security issues I mentioned. -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
I have a few questions: Whats the difference between chmod 777 /var/lib/twiki/working/tmp and chmod 777 /tmp/twiki as that is all it seems to me you're suggesting is the difference between a CVE raised on a maybe problem that requires a very odd set of circumstances and what you have labled as a grave error. The tmp dir is used (mostly from apache, but also from the command line and cron jobs) for session files and rcs for its very short lived temporary files. working/tmp is NOT used for any web data, it is used by rcs (presumably responsible for its own security) and for session files which have their own uniqued filename. and so, I think you are in error, and need to read the code a little before you make assertions like this. Sven On Sun, 2007-10-21 at 12:26 +0200, Nico Golde wrote: Hi Sven, * Sven Dowideit [EMAIL PROTECTED] [2007-10-21 11:57]: ok, following the url.. Nico, you seem to me to be incorrect. 777 is on the working/tmp dir only, which is not used for any web content. I didn't say this but twiki is using it, no? Lets assume you put a symlink in there with a name of a tmp file that has to be written pointing to some web content (I said web content because apache does not run with root) then twiki will overwrite the file following the symlink because the file names of the plugins are predictable. If this is not the case I wonder why www-data is the group name. Also, as the twiki cgi scripts are callable from the command line by any user, requiring the working/tmp dir to be writable by any user, I can't think of any way that this is fixable? Then let them use /tmp but create unique file names using for example mkstemp. Kind regards Nico -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
mmm, following the link makes me even less convinced that there is a problem. the working/tmp dir is used for rcs tmp files, and twiki session files, both of which use randomised unique filenames. as the Wikipedia page suggests that the problem is avoided by using randomised filenames, we seem to be done? Nico, If i were ignoring what you wrote, I would not be replying. I have unfortunately found nothing so far to make me understand that there in fact is a problem. Evey extra detail you guys are giving me, is reinforcing this opinion As Holger points out, I am a part time packager (over debian, osx, windows, rpm, and soon to be Solaris and maybe a few more), so I'm looking to understand, not just to blindly agree to whatever you say. Sven On Tue, 2007-10-23 at 11:34 +0200, Holger Levsen wrote: Nico, On Tuesday 23 October 2007 10:51, you wrote: NOONE SAID THERE IS ANY WEBCONTENT STORED IN THERE, CAN YOU PLEASE JUST READ UP WHAT A SYMLINK ATTACK IS? THANKS! This is the last mail from my side as long as you ignore what I wrote in previous mails. I understand your frustration (that so many packages have the same security problems over and over again), but there is no need to yell at someone. As I see it, Sven is perfectly willing and able to fix issues in his code, it just seems to me, that he doesnt understand symlink attacks, probably because he never heard about them. The solution to make him understand this, is not to yell at him and stop explaining, but rather continue explaining in a friendly way. Sven, please ignore Nicos tone and have a look at http://en.wikipedia.org/wiki/Symlink_race :-) Thanks regards happy hacking, Holger -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
neat summary Joey :)
The reason that I made it world writeable, is that twiki cgi's can be
run from the command line by anyone, and in doing so, create a session
file.
This is used by cronjobs, and so that users can script additions to
topics etc.
Basically, like much of the rest of TWiki, its security is a crock :(
Do you have any suggestions (other than re-writing TWiki?) or should I
just disable that funcionality and run away?
Sven
On Tue, 2007-10-23 at 16:45 -0400, Joey Hess wrote:
Sven Dowideit wrote:
the working/tmp dir is used for rcs tmp files, and twiki session files,
both of which use randomised unique filenames.
rcs opens its temp files with O_EXCL, so I don't think it will be vulnerable
to symlink attacks.
In twiki 4.1.2, I quickly found some temp file problems.
./lib/TWiki/Client.pm:open( IPMAP, '',
$TWiki::cfg{TempfileDir}.'/ip2sid') ||
Trivial to exploit if you can write to $TWiki::cfg{TempfileDir}.
./lib/TWiki.pm:my $passthruFilename = $TWiki::cfg{TempfileDir} .
'/passthru_' . $uid;
./lib/TWiki.pm:open(F, $passthruFilename) || die {TempfileDir} cache
not writable $!;
This $uid md5sum would be hard to guess. I still don't consider this
code fully secure from temp file attacks since it does not use O_EXCL.
I have not done a complete audit. Writing temp files to a 777 directory
scares me. What if another user deletes the temp file (since the directory
is not +t, anyone can)? What if a user deletes a temp file and replaces
the data in it with other data, which is then read back in? (For example,
the passthru_ file above is later read back in by another instance of twiki.)
Could a buffer overflow, malicious data, or incorrect data be substituted in
this way and used to attack twiki or rcs? Rather than trying to answer these
questions, I'd recommend tightening the temp directory permissions.
--
Professional Wiki Innovation and Support
Sven Dowideit - http://DistributedINFORMATION.com
A WikiRing Partner http://wikiring.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
Bizzre, I don't have any email from Holger, at any time, nor did I search for a new sponsor. Ardo has been sponsoring this package for the last few years, with Amaya helping me out both with the debian bits, and with uploading when things were busy. so, um, what are you debian people up to? I also did not receive any information that there was an issue with this package, so I guess there's a communications problem somewhere? anyone want to fill me in? (yes, I am not a DD, and have little time nor interest in becoming one, I'm just trying hard to make twiki easier for people) Sven On Sat, 2007-10-20 at 15:06 -0500, Ardo van Rangelrooij wrote: Nico Golde wrote: Hi, errm why on earth did you (Sven) search for another sponsor when Holger was looking into your package but decided not to upload it because of the changes you made? You searched a new sponsor with exactly the same debdiff. I am sorry but it looks like this was intentionally because I Cced you in the mail stating why there is no way for this package to get uploaded: http://lists.alioth.debian.org/pipermail/secure-testing-team/2007-October/001416.html Why did you ignore this, and Ardo, why did you upload this? Nico, Oops! Totally overlooked this one. Yes, that should never have been uploaded. (For a moment I was afraid I took the wrong version from Sven's website, but this is the only version for this fix.) I also wasn't aware of you being involved in this. Sven, This is not good. Let's never do this again. Thanks, Ardo -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444982: marked as done (CVE-2007-5193 information disclosure in default configuration)
ok, following the url.. Nico, you seem to me to be incorrect. 777 is on the working/tmp dir only, which is not used for any web content. Also, as the twiki cgi scripts are callable from the command line by any user, requiring the working/tmp dir to be writable by any user, I can't think of any way that this is fixable? I guess for me to act on this, I'll need more information from you. TWiki does have a very painful set of assumptions, which don't map easily to debian, and as a non-DD, I need much more help than what you've provided. Sven -- - chmod 777 /tmp/twiki - chown $TWIKI_OWNER.www-data /tmp/twiki + chmod 777 /var/lib/twiki/working/tmp + chown $TWIKI_OWNER.www-data /var/lib/twiki/working/tmp #add softlinks to make adding plugins easier () if [ ! -e /var/lib/twiki/lib ]; then Thanks that you did not sponsor this upload. Why is setting the rights to 777 done here? This would enable every user on the system to delete web content via a symlink attack. The old solution is of course not secure too. Please fix this. Kind regards Nico On Sun, 2007-10-21 at 19:22 +1000, Sven Dowideit wrote: Bizzre, I don't have any email from Holger, at any time, nor did I search for a new sponsor. Ardo has been sponsoring this package for the last few years, with Amaya helping me out both with the debian bits, and with uploading when things were busy. so, um, what are you debian people up to? I also did not receive any information that there was an issue with this package, so I guess there's a communications problem somewhere? anyone want to fill me in? (yes, I am not a DD, and have little time nor interest in becoming one, I'm just trying hard to make twiki easier for people) Sven On Sat, 2007-10-20 at 15:06 -0500, Ardo van Rangelrooij wrote: Nico Golde wrote: Hi, errm why on earth did you (Sven) search for another sponsor when Holger was looking into your package but decided not to upload it because of the changes you made? You searched a new sponsor with exactly the same debdiff. I am sorry but it looks like this was intentionally because I Cced you in the mail stating why there is no way for this package to get uploaded: http://lists.alioth.debian.org/pipermail/secure-testing-team/2007-October/001416.html Why did you ignore this, and Ardo, why did you upload this? Nico, Oops! Totally overlooked this one. Yes, that should never have been uploaded. (For a moment I was afraid I took the wrong version from Sven's website, but this is the only version for this fix.) I also wasn't aware of you being involved in this. Sven, This is not good. Let's never do this again. Thanks, Ardo -- Professional Wiki Innovation and Support Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414361: New upstream release (4.1.2) available
I thought that Debian was supposed to be so close to releasing Etch that I shouldn't change upstream versions so dramatically? Sven On Sun, 2007-03-11 at 09:12 +0100, Michael Biebl wrote: Package: twiki Severity: wishlist Hi, please consider packaging the latest version, which is 4.1.2 atm of this writing. Thanks, Michael -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.21-rc3 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412057: twiki: apache.conf should not allow other IP for configure than localhost by default
yes, its a bit weird. 192.168.1.10 is non-routable, but never the less its wrong. I don't know if its important though, as you say, the comma removes it, the ip is local only. I'll fix it next time i have real computer access - I'm in transit to Zurich at the moment, so it'll be another week (i think) Sven -- Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410803: twiki: postinst relies on data in /usr/share/doc
hehe, sorry, and thanks - I've already fixed it, and a few other recomendations that were made BUT, I'd love some one to upload it for me the new version is at http://members.iinet.net.au/~spos/twiki_4.0.5-9.dsc and If this version can go into Etch... even better. I was thrilled about the amount of feedback i got yesterday - thanks everyone of you, and if you find more, i'll be quite happy to fix them too. Sven On Wed, 2007-02-14 at 10:42 +0100, Frank Küster wrote: tags 410803 patch thanks Gerfried Fuchs [EMAIL PROTECTED] wrote: So please move the starter kit to /usr/share/twiki and symlink it from the doc directory, if you really want to have it available from there, too - and don't forget to change the tar extract line in the postinst script. Since the location is mentioned in README.Debian, I didn't think the symlinks are needed. Here's a patch. As usual, it comes with an offer to NMU the package. Regards, Frank -- Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410256: fixed package available
I've made a new version of the package (that fixes this, and other issues), and its waiting in my sponsor's queue http://members.iinet.net.au/~spos/twiki_4.0.5-9_all.deb -- Sven Dowideit - http://DistributedINFORMATION.com A WikiRing Partner http://wikiring.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410256: [TWiki-Security] TWiki Security Alert: Arbitrary code execution in session files (CVE-2007-0669)
Package: twiki
Version: 1:4.0.5-7
I expect to look into this on the weekend
Sven
On Thu, 2007-02-08 at 09:31 -0800, Peter Thoeny wrote:
This is a security advisory for TWiki installations:
Local users may cause TWiki to execute arbitrary code
by creating CGI session files.
* Vulnerable Software Version
* Attack Vectors
* Impact
* Severity Level
* MITRE Name for this Vulnerability
* Details
* Countermeasures
* Hotfix for TWiki 4.x
* Hotfix for older TWikis using SessionPlugin
* Authors and Credits
* Action Plan with Timeline
* Feedback
* External Links
---++ Vulnerable Software Version
* TWikiRelease04x01x00 -- TWiki-4.1.0.zip
* TWikiRelease04x00x05 -- TWiki-4.0.5.zip
* TWikiRelease04x00x04 -- TWiki-4.0.4.zip
* TWikiRelease04x00x03 -- TWiki-4.0.3.zip
* TWikiRelease04x00x02 -- TWiki-4.0.2.zip
* TWikiRelease04x00x01 -- TWiki-4.0.1.zip
* TWikiRelease04x00x00 -- TWiki-4.0.0.zip
* Any previous TWiki version using SessionPlugin [6]
---++ Attack Vectors
Write access to global /tmp directory (or CGI session
directory, if different). This can be either directly
on file level (such as on a shared host), or via an
HTTP vulnerability of a third party web application.
---++ Impact
Under the assumption that an intruder has write access
to the /tmp directory (or CGI session directory), such
as with a vulnerability of another web application
running on the same server, it is possible to execute
arbitrary Perl code with the privileges of the web
server process, such as user nobody.
---++ Severity Level
The TWiki SecurityTeam [2] triaged this issue as
documented in TWikiSecurityAlertProcess [3] and
assigned the following severity level:
* Severity 2 issue: The TWiki installation is
compromised
---++ MITRE Name for this Vulnerability
The Common Vulnerabilities and Exposures project has
assigned the name CVE-2007-0669 [4] to this
vulnerability.
---++ Details
Your site may be vulnerable if:
1. You run one of the vulnerable TWiki versions, and
2. You have *not* reconfigured the CGI session
directory $cfg{Sessions}{Dir} to a private
directory
In particular, disabling the CGI session tracking via
$cfg{UseClientSessions} is *not* sufficient to protect
against this vulnerability, since there is session
cleanup code that runs regardless of whether sessions
are enabled or not.
---++ Countermeasures
* Restrict access to the TWiki server on file level
and HTTP.
* If on a shared host, move TWiki to a dedicated
host.
* Upgrade to TWiki Release 4.1.1 [5] (recommended)
* Apply a hotfix indicated below.
NOTE: The hotfix is known to prevent the current
attacks, but it might not be a complete fix.
---++ Hotfix for TWiki 4.x
In configure, change $cfg{Sessions}{Dir} to a private
directory (one which is only readable and writable by
the user your web server is running as, and is not
served as web content to remote users). The recommended
fix is to make a $cfg{DataDir}/session_tmp directory
owned by the user Apache is running as, change its
permissions to 0700 (drwx--), and set
$cfg{Sessions}{Dir} to that directory.
Upgrading to TWiki 4.1.1 is recommended; the session
files are cleaned up by timestamp, i.e. no longer
executed. TWiki 4.1.1 will create and use the
/tmp/twiki directory by default to store the session
files.
---++ Hotfix for older TWikis using SessionPlugin
This section details the attack vectors, details, and
countermeasures for this vulnerability as it applies
to the SessionPlugin [6]. This section does not apply
to TWiki versions 4.0 and up, which use built-in
session tracking.
Vulnerable software version
* Plugins.SessionPlugin 1.0 -- SessionPlugin.zip
(attachment versions 1-5)
* Plugins.SessionPlugin 2.0-2.992 --
SessionPlugin.zip (attachment versions 6-8)
Attack Vectors
* For SessionPlugin 1.000:
* Write access to the $cfg{DataDir}/.session
directory, which in some cases may be created
world-writable for local users.
* For SessionPlugin 2.0-2.992:
* Write access to global /tmp directory. This
can be either directly on file level (such as
shared host), or HTTP vulnerability of a third
party web application.
Countermeasures
* For SessionPlugin 1.000 (attachment versions 1-5
from the SessionPlugin topic):
* Ensure that the $cfg{DataDir}/.session directory
exists, is owned by the user Apache is running
as, and has 0700 permissions (drwx--).
* For SessionPlugin 2.9 (attachment versions 6-8 from
the SessionPlugin topic):
* Upgrade to Plugins.SessionPlugin 2.992
(attachment version 9 from the SessionPlugin
topic).
---++ Authors and Credits
* Credit to Andrew
Bug#406503: twiki: Fails to start when no sample data is installed
yes, TWiki does not run without a dataset. if you don't use the sample topic set, the presumption is that you are either upgrading, re-installing, or using your own. Luca, can you suggest a better wording for the user prompt? Cheers Sven (ps, I'm without computer for the next 3 weeks) On 11/01/2007, at 6:09 PM, Luca Venturini wrote: Package: twiki Version: 1:4.0.5-7 Severity: important Tags: experimental We had problems installing the package without sample data. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages twiki depends on: ii apache-common 1.3.33-6sarge3 support files for all Apache webse ii apache2-common2.0.54-5sarge1 next generation, scalable, extenda ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-1 a perl library for finding Longest ii libcgi-session-perl 3.95-2 Persistent session data in CGI app ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message digest algorith ii liberror-perl 0.15-6 Perl module for error/ exception ha ii liblocale-maketext-lexico 0.49-1 Lexicon-handling backends for Loc ii libtext-diff-perl 0.35-2 Perform diffs on files and record ii perl [libmime-base64-perl 5.8.4-8sarge5 Larry Wall's Practical Extraction ii perl-modules [libnet-perl 5.8.4-8sarge5 Core Perl modules ii rcs 5.7-15 The GNU Revision Control System -- debconf information: * twiki/apacheUserCreationNote: * twiki/samplefiles: true * twiki/wikiwebmaster: [EMAIL PROTECTED] * twiki/defaultUrlHost: http://www.wikifirm.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403695: twiki: Cannot set WEBLOGOIMG
I think these are settings that are still set on the
TWiki.TWikiPreferences or Main.TWikiPreferences topic, not via
configure.
Basically, only settings that are accessible via the configure
interface, are gotten from LocalSite.cfg.
its an interesting suggestion for upstream - you could create a topic
in the Codev web on TWiki.org :)
Cheers
Sven
On 19/12/2006, at 2:57 AM, Paul Szabo wrote:
Package: twiki
Version: 1:4.0.5-5
Severity: minor
I have difficulties with setting WEBLOGOIMG and similar. Though I have
$TWiki::cfg{WEBLOGOIMG}='/twiki/pub/SMSlogo.gif';
$TWiki::cfg{WEBLOGOURL}='WebHome';
in /etc/twiki/LocalSite.cfg, viewing the main wiki page I see (using
view source in the browser):
...
form name=main action=/iw/view/Main/WebHome
table width=100% border=0 cellpadding=3 cellspacing=0
tr
td bgcolor=#C0 rowspan=2 valign=top width=1%
a href=%WEBLOGOURL% rel='nofollow'img src=%
WEBLOGOIMG% border=0 alt=%WEBLOGOALT% //a
/tdtd
a href=/iw/view/Main/WebHomeTWiki/a
...
I can only get the right output by modifying
/var/lib/twiki/templates/twiki.tmpl and hard-coding these values.
What am I doing wrong?
Thanks,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/
psz/
School of Mathematics and Statistics University of Sydney
Australia
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-spb1.7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages twiki depends on:
ii apache-common 1.3.33-6sarge3 support files for all
Apache webse
ii apache2-common2.0.54-5sarge1 next generation,
scalable, extenda
ii debconf [debconf-2.0] 1.4.30.13 Debian configuration
management sy
ii libalgorithm-diff-perl1.19.01-1 a perl library for
finding Longest
ii libcgi-session-perl 3.95-2 Persistent session
data in CGI app
ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message
digest algorith
ii liberror-perl 0.15-6 Perl module for error/
exception ha
ii liblocale-maketext-lexico 0.49-1 Lexicon-handling
backends for Loc
ii libtext-diff-perl 0.35-2 Perform diffs on files
and record
ii perl [libmime-base64-perl 5.8.4-8sarge5 Larry Wall's Practical
Extraction
ii perl-modules [libnet-perl 5.8.4-8sarge5 Core Perl modules
ii rcs 5.7-15 The GNU Revision
Control System
-- debconf information:
* twiki/apacheUserCreationNote:
* twiki/samplefiles: true
* twiki/wikiwebmaster: [EMAIL PROTECTED]
* twiki/defaultUrlHost: http://iw.maths.usyd.edu.au
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403464: twiki: still depends on old apache-common
heck y, sorry, blindness causes bad side-effects :( mind you, I personally wish debian would see the light, and create a webserver-cgi pseudopackage, with a universal configuration builder that way little packages like twiki would not have dependancies on _any_ particular versions... Cheers Sven expect a fix within the week - if not, Please, Please email me :) On 17/12/2006, at 1:12 PM, Laurent Bonnaud wrote: Package: twiki Version: 1:4.0.5-5 Severity: wishlist Hi, in its Depends: field, twiki has apache-common, apache2-common | apache2.2-common which forces the installation of the old package apache-common. I would like to get rid of all apache 1.3 related packages. So would it be possible to have a Depends: field that would look like the following: apache-common | apache2-common | apache2.2-common -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (100, 'unstable'), (99, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages twiki depends on: ii apache-common 1.3.34-4 support files for all Apache webse ii apache2.2-common 2.2.3-3.2 Next generation, scalable, extenda ii debconf [debconf-2.0] 1.5.10 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-2 a perl library for finding Longest ii libcgi-session-perl 4.14-1 Persistent session data in CGI app ii libdigest-sha1-perl 2.11-1 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/ exception ha ii liblocale-maketext-lexicon-pe 0.62-1 Lexicon-handling backends for Loc ii libtext-diff-perl 0.35-2 Perform diffs on files and record ii perl [libmime-base64-perl]5.8.8-7Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.8-7Core Perl modules ii rcs 5.7-18 The GNU Revision Control System twiki recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367973: Twiki - about to miss a release?
true, I don't do much, other than update the debian package at http:// members.iinet.net.au/~spos once a month or two, and send it off to my sponsor. As a TWiki developer, rather than a debian developer, I don't feel supported by you guys, just attacked, but none the less, I maintain what i can. Sven On 04/11/2006, at 3:52 AM, Antony Gelberg wrote: I haven't cc'd the bug 367973 that this comes from - Steve if you want the background please see http://bugs.debian.org/cgi-bin/ bugreport.cgi?bug=367973 and http://bugs.debian.org/twiki. Sven Dowideit: its stuff like this that just keeps depressing me into not finishing the work i do packaging twiki for debian. Stuff like what? I think Thijs's point is that you appear to not be doing much, for whatever reason, and twiki is going to miss another release which is a shame and inconvenience for users. There is a 247-day old bug relating to the latest release last February, and you haven't even acknowledged it. your officiousness is a joy, ta. same sort of thing as when just before the last debian release came out, and some one helpfully filed an un-reproducible RC bug, that didn't happen for anyone else, but no debian developer came out to help. you guys really truly don't want help from people outside your klic do you. I'm not really sure what you're complaining about. Please maintain the package or RFA it. If you are maintaining it, it certainly looks like you aren't. -- Antony Gelberg | Open Source Consultancy Wayforth | Software Development 020 7247 1011 | Website Design http://www.wayforth.co.uk | Peace-of-mind Support -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367973: twiki: CVE-2006-1387: DoS with INCLUDE
its stuff like this that just keeps depressing me into not finishing the work i do packaging twiki for debian. your officiousness is a joy, ta. same sort of thing as when just before the last debian release came out, and some one helpfully filed an un-reproducible RC bug, that didn't happen for anyone else, but no debian developer came out to help. you guys really truly don't want help from people outside your klic do you. Thijs Kinkhorst wrote: CVE-2006-1387: TWiki 4.0, 4.0.1, and 20010901 through 20040904 allows remote authenticated users with edit rights to cause a denial of service (infinite recursion leading to CPU and memory consumption) via INCLUDE by URL statements that form a loop, such as a page that includes itself. I could look into fixing this, but since twiki has: * multiple open security issues without any maintainer response for many months now, * plus no maintainer response to the majority of the other open bugs, * trivial things not fixed, * never been part of a stable release, the best is to just remove it from testing. I'm cc'ing MIA since the maintainer doesn't have any visible activity for over a year. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332439: #332439 - twiki: Undeclared dependency on package bc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /usr/lib/cgi-bin/nagios/grouplist.cgi is not a twiki script Sven -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEARQpPAwzu0QrW+kRAp3sAJ9A1mjzWdKxIwdGlcqStM5IWYR/tgCcCG8r ja3TgtTAVpMivufEDG5zaaY= =JPiM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#211237: twiki: crontab and .mailnotify time stamps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I implemented the .mailnotify suggestion in (20030201-3) - but i've been reluctant to create a crontab magically Sven -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEARspPAwzu0QrW+kRAnMbAKCSQLWheqyJuZICRfsyKur12eRp2QCgp62r zy+n/Hu8hSZ4uiKEYYn/ZO8= =/uyc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330733: twiki: INCLUDE function allows arbitrary shell command execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
while I think its very reasonable for you to send along these
advisories, and even doing so as a BTS bug wothout testing them
I think its incredibly rude to do so without saying that you have not
tested it out.
please, if you enter a bug report, tell the maintainer what you have or
have not done, that way they can deal more appropriatly with the issue
(in the cases where the core issue has been dealt with (thanks to
Florian!) I'm very busy helping out upstream, and i'm sure this
situation _should_ apply to others (i object to the number of debian
maintainers that are not appropriatly active upstream)
however, other than my rant :) thanks for the notification, its
important (i'm still notifying people now)
Sven
micah wrote:
Sven,
I have not attempted to reproduce this in the debian package, I'm
tracking known vulnerabilities with the testing-security team. When I
see a new CVE id assigned to a package and no bugs filed on that package
regarding that CVE, and no entries in the changelogs noting that it has
been fixed, I tend to believe that it hasn't been because it is a rare
package maintainer who has security issues fixed before they are
discovered or announced.
Additionally, the advisory indicates that the version in debian
(20040902-3) is affected, as the only versions it indicates are safe is
the TWikiRelease01Sep2004 patched with Florian Weimer's
UncoordinatedSecurityAlert23Feb2005 patches. Without any indication in
the BTS or in changelogs, I assume that the package is affected because
the version numbers typically are very good indicators. Admittedly, you
could very well have addressed this issue, and I have a feeling that you
have as Florian is very active in Debian. If so, I'd be happy to know
that, and we can close this bug, so I can note it in the
testing-security database.
Unfortunately, if I had to try every exploit, even those without
published exploits, for every CVE assigned, there would be a net loss. I
understand that this means this is an annoyance to you to get a grave
bug report for something that you may have addressed, however it ends up
being a good thing because then we know for sure, and can better track
vulnerabilities in Debian. It is better to be asked once if this is an
issue and have it properly noted, than for Debian to not pay attention
to anything at all and be riddled with security holes.
micah
Sven Dowideit wrote:
excellent.
Micah, did you manage to reproduce this in the debian package at all?
you see, the debian package is significantly more secure than the
upstream version, and as you've marked it as grave, I presume that you
have found a way to make it happen. (as when I had a go, i did not get
the exploit (i got a unhelpful, but correct error message invalid
number argument at /usr/share/perl5/TWiki.pm line 3339.)
could you please either tell me how to reproduce the problem in the
current debian package, or close it?
Cheers
Sven
Micah Anderson wrote:
Package: twiki
Version: 20040902-3
Severity: grave
Tags: security
Justification: user security hole
A new security bug in twiki showed up today:
http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithInclude
An attacker is able to execute arbitrary shell commands with the
privileges of the web server process. The TWiki INCLUDE function
enables a malicious user to compose a command line executed by the
Perl backtick (`) operator.
The rev parameter of the INCLUDE variable is not checked properly for
shell metacharacters and is thus vulnerable to revision numbers
containing pipes and shell commands. The exploit is possible on
included topics with two or more revisions.
Example INCLUDE variable exploiting the rev parameter:
%INCLUDE{ Main.TWikiUsers rev=2|less /etc/passwd }%
The same vulnerability is exposed to all Plugins and add-ons that use
TWiki::Func::readTopicText function to read a previous topic revision.
This has been tested on TWiki:Plugins.RevCommentPlugin and
TWiki:Plugins.CompareRevisionsAddon.
If access to TWiki is not restricted by other means, attackers can use
the revision function with or without prior authentication, depending
on the configuration.
The Common Vulnerabilities and Exposures project has assigned the name
CAN-2005-3056 to this vulnerability. Please include this number in any
changelogs fixing this.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDQid7PAwzu0QrW+kRAsEoAJ9+GXExEvN2Z2VWChFT4PdDkzLhhwCfVsg6
PUP0bbpDuBHe7eBSLk5ZPQY=
=+J/s
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL
Bug#330733: twiki: INCLUDE function allows arbitrary shell command execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Yes, defiantly
I have not found any way to exploit the debian package using any thus
far found methods. Florians patch get in the way every time :)
Sven
micah wrote:
Does this mean that the twiki (20040902-3) in Debian is not vulnerable
and this bug report can be closed?
Micah
Sven Dowideit wrote:
while I think its very reasonable for you to send along these
advisories, and even doing so as a BTS bug wothout testing them
I think its incredibly rude to do so without saying that you have not
tested it out.
please, if you enter a bug report, tell the maintainer what you have or
have not done, that way they can deal more appropriatly with the issue
(in the cases where the core issue has been dealt with (thanks to
Florian!) I'm very busy helping out upstream, and i'm sure this
situation _should_ apply to others (i object to the number of debian
maintainers that are not appropriatly active upstream)
however, other than my rant :) thanks for the notification, its
important (i'm still notifying people now)
Sven
micah wrote:
Sven,
I have not attempted to reproduce this in the debian package, I'm
tracking known vulnerabilities with the testing-security team. When I
see a new CVE id assigned to a package and no bugs filed on that package
regarding that CVE, and no entries in the changelogs noting that it has
been fixed, I tend to believe that it hasn't been because it is a rare
package maintainer who has security issues fixed before they are
discovered or announced.
Additionally, the advisory indicates that the version in debian
(20040902-3) is affected, as the only versions it indicates are safe is
the TWikiRelease01Sep2004 patched with Florian Weimer's
UncoordinatedSecurityAlert23Feb2005 patches. Without any indication in
the BTS or in changelogs, I assume that the package is affected because
the version numbers typically are very good indicators. Admittedly, you
could very well have addressed this issue, and I have a feeling that you
have as Florian is very active in Debian. If so, I'd be happy to know
that, and we can close this bug, so I can note it in the
testing-security database.
Unfortunately, if I had to try every exploit, even those without
published exploits, for every CVE assigned, there would be a net loss. I
understand that this means this is an annoyance to you to get a grave
bug report for something that you may have addressed, however it ends up
being a good thing because then we know for sure, and can better track
vulnerabilities in Debian. It is better to be asked once if this is an
issue and have it properly noted, than for Debian to not pay attention
to anything at all and be riddled with security holes.
micah
Sven Dowideit wrote:
excellent.
Micah, did you manage to reproduce this in the debian package at all?
you see, the debian package is significantly more secure than the
upstream version, and as you've marked it as grave, I presume that you
have found a way to make it happen. (as when I had a go, i did not get
the exploit (i got a unhelpful, but correct error message invalid
number argument at /usr/share/perl5/TWiki.pm line 3339.)
could you please either tell me how to reproduce the problem in the
current debian package, or close it?
Cheers
Sven
Micah Anderson wrote:
Package: twiki
Version: 20040902-3
Severity: grave
Tags: security
Justification: user security hole
A new security bug in twiki showed up today:
http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithInclude
An attacker is able to execute arbitrary shell commands with the
privileges of the web server process. The TWiki INCLUDE function
enables a malicious user to compose a command line executed by the
Perl backtick (`) operator.
The rev parameter of the INCLUDE variable is not checked properly for
shell metacharacters and is thus vulnerable to revision numbers
containing pipes and shell commands. The exploit is possible on
included topics with two or more revisions.
Example INCLUDE variable exploiting the rev parameter:
%INCLUDE{ Main.TWikiUsers rev=2|less /etc/passwd }%
The same vulnerability is exposed to all Plugins and add-ons that use
TWiki::Func::readTopicText function to read a previous topic revision.
This has been tested on TWiki:Plugins.RevCommentPlugin and
TWiki:Plugins.CompareRevisionsAddon.
If access to TWiki is not restricted by other means, attackers can use
the revision function with or without prior authentication, depending
on the configuration.
The Common Vulnerabilities and Exposures project has assigned the name
CAN-2005-3056 to this vulnerability. Please include this number in any
changelogs fixing this.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-BEGIN PGP
Bug#330733: twiki: INCLUDE function allows arbitrary shell command execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
excellent.
Micah, did you manage to reproduce this in the debian package at all?
you see, the debian package is significantly more secure than the
upstream version, and as you've marked it as grave, I presume that you
have found a way to make it happen. (as when I had a go, i did not get
the exploit (i got a unhelpful, but correct error message invalid
number argument at /usr/share/perl5/TWiki.pm line 3339.)
could you please either tell me how to reproduce the problem in the
current debian package, or close it?
Cheers
Sven
Micah Anderson wrote:
Package: twiki
Version: 20040902-3
Severity: grave
Tags: security
Justification: user security hole
A new security bug in twiki showed up today:
http://twiki.org/cgi-bin/view/Codev/SecurityAlertExecuteCommandsWithInclude
An attacker is able to execute arbitrary shell commands with the
privileges of the web server process. The TWiki INCLUDE function
enables a malicious user to compose a command line executed by the
Perl backtick (`) operator.
The rev parameter of the INCLUDE variable is not checked properly for
shell metacharacters and is thus vulnerable to revision numbers
containing pipes and shell commands. The exploit is possible on
included topics with two or more revisions.
Example INCLUDE variable exploiting the rev parameter:
%INCLUDE{ Main.TWikiUsers rev=2|less /etc/passwd }%
The same vulnerability is exposed to all Plugins and add-ons that use
TWiki::Func::readTopicText function to read a previous topic revision.
This has been tested on TWiki:Plugins.RevCommentPlugin and
TWiki:Plugins.CompareRevisionsAddon.
If access to TWiki is not restricted by other means, attackers can use
the revision function with or without prior authentication, depending
on the configuration.
The Common Vulnerabilities and Exposures project has assigned the name
CAN-2005-3056 to this vulnerability. Please include this number in any
changelogs fixing this.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDPE2aPAwzu0QrW+kRAqZLAJ90bJEaXjUiwrkNcOu/U25JiLXAjgCeMoiy
VRnVrGHfBUXGaRpLZR8JP0M=
=5784
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317653: twiki: conflicts with libtext-diff-perl
Isn't this already fixed in the latest version og the package? (20040902-3) twiki (20040902-2) unstable; urgency=emergency . * removed Text::Diff, added depends libtext-diff-perl (Closes #29522) * set twikiLibPath to /usr/share/perl5 in setlib.cfg (Closes #296461) * applied robustness patch from Florian Weimer [EMAIL PROTECTED] (Closes #296655) * added libunicode-maputf8-perl suggestion (Closes #297031) * default to use sendmail (Closes #252439) * updated fr.po file (Closes #296149, #298750) -Original Message- From: Andrew Nott [mailto:[EMAIL PROTECTED] Sent: Sunday, 10 July 2005 3:08 PM To: Debian Bug Tracking System Subject: Bug#317653: twiki: conflicts with libtext-diff-perl Package: twiki Version: 20040902-1 Severity: normal Both packages include /usr/share/perl5/Text/Diff.pm, preventing installing both at once. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.29-linode39-1um Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages twiki depends on: ii apache-common 1.3.33-6 support files for all Apache webse ii apache2-common2.0.54-4 next generation, scalable, extenda ii debconf 1.4.51 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-1 a perl library for finding Longest ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message digest algorith ii libnet-perl 1:1.19-1 Implementation of Internet protoco ii perl [libmime-base64-perl]5.8.7-3Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.7-3Core Perl modules ii rcs 5.7-16 The GNU Revision Control System twiki recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305793: twiki: Attach files to TWiki topics fails after update
bingo, brilliant, you've found the real problem, and it also explains why i never found it. I habitually add a comment, expecting it to exercise more code paths ;( happens on my system too - so this one i can fix :) Cheers Sven On Tue, 2005-05-10 at 10:56 +0200, Andrea Ceccanti wrote: Il giorno sab, 07-05-2005 alle 19:22 +1000, Sven Dowideit ha scritto: While I'd agree that this is pretty grave really, I can't reproduce this. is there any more info that you can give me? are you able to create / edit topics, add an attachement to a new topic, or anything like this? I am able create/edit topics. I am also able to add attachments, but i have to fill the comment field in the HTML form to make it work. I used to leave it blank and the attach operation worked as well. I don't think a user should be forced to provide a comment for an attachment. I think this is the main difference with previous versions. Andrea Sven On Fri, 2005-04-22 at 11:09 +0200, Andrea Ceccanti wrote: Package: twiki Version: 20040902-3 Severity: grave Tags: experimental Justification: renders package unusable After the update, it is impossible to attach files to TWiki topics. I report here the TWiki error message: Topic save error During save of file Main.AndreaCeccanti an error was found by the version control system. Please notify your TWiki administrator. Save attachment error /usr/bin/ci -q -l -m%COMMENT|U% -t-none -w%USERNAME|S% %FILENAME|F% ci: missing message for -m option Go back in your browser and save your changes locally. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages twiki depends on: ii apache2-common2.0.53-5 next generation, scalable, extenda ii debconf 1.4.30.13 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-1 a perl library for finding Longest ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message digest algorith ii libtext-diff-perl 0.35-2 Perform diffs on files and record ii perl [libmime-base64-perl]5.8.4-8Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.4-8Core Perl modules ii rcs 5.7-14 The GNU Revision Control System -- debconf information: * twiki/apacheUserCreationNote: * twiki/samplefiles: true * twiki/wikiwebmaster: [EMAIL PROTECTED] * twiki/defaultUrlHost: http://blackbird.tapas.cs.unibo.it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307299: Perl taint error on TWiki diffs page after twiki/apache upgrade
I'm sorry, but I cannot re-produce this. and when testing your suggested change, I get other errors in my log. is there any more information you can give me? (what topics, what kind of changes, which particular diffs link) Sven On Mon, 2005-05-02 at 07:01 -0400, [EMAIL PROTECTED] wrote: Package: twiki Version: 20040902-3 Problem occured after upgrading: twiki 20040902-1.1 - 20040902-3 apache2-common 2.0.53-5 - 2.0.54-2 (other packages were also upgraded at the same time, complete list below) Perl v5.8.4 Linux twiki 2.4.25 #1 SMP Fri Mar 5 10:32:46 EST 2004 i686 GNU/Linux libc6 version 2.3.2.ds1-21 Problem description --- Immediately after upgrading Apache and TWiki as described above we started getting this error: Insecure dependency in exec while running with -T switch at /usr/share/perl5/TWiki.pm line 3454. Whenever we clicked the Diffs link on a TWiki topic. The problem seems to start on line 378 of /usr/share/perl5/TWiki/UI/RDiff.pm my $rev1 = $query-param( rev1 ); At this point rev1 (and rev2) are tainted. On line 410 (411 for rev2) they are run through a regexp: $rev1 =~ s/r?1\.//go; # cut 'r' and major but it does not seem sufficient to untaint them. Changing the line to something like: ($rev1) = $rev1 =~ /r?1\.(\d*)/; # cut 'r' and major does work. Complete aptitude log from upgrade: [EMAIL PROTECTED]:~# more /var/log/aptitude Aptitude 0.2.15.8: log report Sun May 1 13:44:01 2005 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 72 packages, and remove 0 packages. 633kB bytes of disk space will be freed === [HOLD] ldap-utils [HOLD] mutt [UPGRADE] apache2-common 2.0.53-5 - 2.0.54-2 [UPGRADE] apache2-mpm-prefork 2.0.53-5 - 2.0.54-2 [UPGRADE] apache2-utils 2.0.53-5 - 2.0.54-2 [UPGRADE] aptitude 0.2.15.8-1 - 0.2.15.9-2 [UPGRADE] base-config 2.53.7 - 2.53.8 [UPGRADE] cpp-3.3 1:3.3.5-8 - 1:3.3.5-12 [UPGRADE] dash 0.5.2-2 - 0.5.2-4 [UPGRADE] debconf 1.4.30.11 - 1.4.30.13 [UPGRADE] debconf-i18n 1.4.30.11 - 1.4.30.13 [UPGRADE] debconf-utils 1.4.30.11 - 1.4.30.13 [UPGRADE] fakeroot 1.2.2 - 1.2.10 [UPGRADE] findutils 4.1.20-5 - 4.1.20-6 [UPGRADE] g++-3.3 1:3.3.5-8 - 1:3.3.5-12 [UPGRADE] gcc-3.3 1:3.3.5-8 - 1:3.3.5-12 [UPGRADE] gcc-3.3-base 1:3.3.5-8 - 1:3.3.5-12 [UPGRADE] glibc-doc 2.3.2.ds1-20 - 2.3.2.ds1-21 [UPGRADE] grep-dctrl 2.1.9 - 2.1.10 [UPGRADE] grub 0.95+cvs20040624-16 - 0.95+cvs20040624-17 [UPGRADE] hotplug 0.0.20040329-21 - 0.0.20040329-22 [UPGRADE] initrd-tools 0.1.77 - 0.1.78 [UPGRADE] irqbalance 0.12-1 - 0.12-2 [UPGRADE] kernel-package 8.125 - 8.132 [UPGRADE] libapache2-mod-auth-pam 1.1.1-4.1 - 1.1.1-6 [UPGRADE] libapache2-mod-perl2 1.999.20-1 - 1.999.21-1 [UPGRADE] libapr0 2.0.53-5 - 2.0.54-2 [UPGRADE] libc6 2.3.2.ds1-20 - 2.3.2.ds1-21 [UPGRADE] libc6-dev 2.3.2.ds1-20 - 2.3.2.ds1-21 [UPGRADE] libc6-i686 2.3.2.ds1-20 - 2.3.2.ds1-21 [UPGRADE] libcupsys2-gnutls10 1.1.23-7 - 1.1.23-10 [UPGRADE] libdbd-mysql-perl 2.9003-4 - 2.9006-1 [UPGRADE] libfreetype6 2.1.7-2.3 - 2.1.7-2.4 [UPGRADE] libfreetype6-dev 2.1.7-2.3 - 2.1.7-2.4 [UPGRADE] libglib2.0-0 2.6.3-1 - 2.6.4-1 [UPGRADE] libglib2.0-dev 2.6.3-1 - 2.6.4-1 [UPGRADE] libltdl3 1.5.6-4 - 1.5.6-6 [UPGRADE] libmysqlclient12 4.0.24-2 - 4.0.24-5 [UPGRADE] libnet-ldap-perl 0.3202-2 - 0.3202-3 [UPGRADE] libnss-ldap 220-1 - 238-1 [UPGRADE] libpam-krb5 1.0-10 - 1.0-12 [UPGRADE] libqt3-compat-headers 3:3.3.3-8 - 3:3.3.4-3 [UPGRADE] libqt3-headers 3:3.3.3-8 - 3:3.3.4-3 [UPGRADE] libqt3c102-mt 3:3.3.3-8 - 3:3.3.4-3 [UPGRADE] libsensors3 1:2.9.0-19 - 1:2.9.1-1 [UPGRADE] libstdc++5 1:3.3.5-8 - 1:3.3.5-12 [UPGRADE] libstdc++5-3.3-dev 1:3.3.5-8 - 1:3.3.5-12 [UPGRADE] liburi-perl 1.30-1 - 1.35-1 [UPGRADE] libusb-0.1-4 2:0.1.10a-6 - 2:0.1.10a-8 [UPGRADE] libxft2 2.1.2-6 - 2.1.7-1 [UPGRADE] locales 2.3.2.ds1-20 - 2.3.2.ds1-21 [UPGRADE] mysql-client 4.0.24-2 - 4.0.24-5 [UPGRADE] mysql-common 4.0.24-2 - 4.0.24-5 [UPGRADE] mysql-server 4.0.24-2 - 4.0.24-5 [UPGRADE] nano 1.2.4-3 - 1.2.4-5 [UPGRADE] nscd 2.3.2.ds1-20 - 2.3.2.ds1-21 [UPGRADE] pdksh 5.2.14-17 - 5.2.14-18 [UPGRADE] pkg-config 0.15.0-4 - 0.16.0-1 [UPGRADE] po-debconf 0.8.22 - 0.8.23 [UPGRADE] qt3-dev-tools 3:3.3.3-8 - 3:3.3.4-3 [UPGRADE] rsync 2.6.3-2 - 2.6.4-2 [UPGRADE] samba 3.0.10-1 - 3.0.14a-1 [UPGRADE] samba-common 3.0.10-1 - 3.0.14a-1 [UPGRADE] sharutils 1:4.2.1-11 - 1:4.2.1-13 [UPGRADE] shorewall 2.2.2-1 - 2.2.3-1 [UPGRADE] sudo 1.6.8p7-1 - 1.6.8p7-1.1 [UPGRADE] twiki 20040902-1.1 - 20040902-3 [UPGRADE] udev 0.056-1 - 0.056-2 [UPGRADE] ulogd 1.02-1 - 1.02-2 [UPGRADE] usbutils 0.70-2 - 0.70-5 [UPGRADE] vim 1:6.3-067+2 - 1:6.3-068+4 [UPGRADE] vim-common 1:6.3-067+2 - 1:6.3-068+4 [UPGRADE] winbind 3.0.10-1 - 3.0.14a-1 [UPGRADE] zsh 4.2.4-8 - 4.2.5-7
Bug#305793: twiki: Attach files to TWiki topics fails after update
While I'd agree that this is pretty grave really, I can't reproduce this. is there any more info that you can give me? are you able to create / edit topics, add an attachement to a new topic, or anything like this? Sven On Fri, 2005-04-22 at 11:09 +0200, Andrea Ceccanti wrote: Package: twiki Version: 20040902-3 Severity: grave Tags: experimental Justification: renders package unusable After the update, it is impossible to attach files to TWiki topics. I report here the TWiki error message: Topic save error During save of file Main.AndreaCeccanti an error was found by the version control system. Please notify your TWiki administrator. Save attachment error /usr/bin/ci -q -l -m%COMMENT|U% -t-none -w%USERNAME|S% %FILENAME|F% ci: missing message for -m option Go back in your browser and save your changes locally. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages twiki depends on: ii apache2-common2.0.53-5 next generation, scalable, extenda ii debconf 1.4.30.13 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-1 a perl library for finding Longest ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message digest algorith ii libtext-diff-perl 0.35-2 Perform diffs on files and record ii perl [libmime-base64-perl]5.8.4-8Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.4-8Core Perl modules ii rcs 5.7-14 The GNU Revision Control System -- debconf information: * twiki/apacheUserCreationNote: * twiki/samplefiles: true * twiki/wikiwebmaster: [EMAIL PROTECTED] * twiki/defaultUrlHost: http://blackbird.tapas.cs.unibo.it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#296461: UpgradeTwiki upgrade script not present/working : fix setlib.cfg
as the original writer of the topic upgrading part of UpgradeTWiki (though mine was really just a test / proof of concept) I would agree, that right now, it would be best not to use the debian package on a large complex twiki config - I'm intending it to become better, and am working on UpgradeTWiki for the next release, but it is a slow process. Thanks for the interest, and the pointers, it has helped both pique my interest, and given me a direction to work in wrt the deb. (I hope one day to be able to call UpgradeTopics from postinst, but at the moment, it scares me too much - there is way too much testing needed to confirm that the upgrade worked, and too much manual labour when things are not simple. Sven On Thu, 2005-02-24 at 10:00 +0100, Olivier Berger wrote: Christopher Huhn [EMAIL PROTECTED] writes: Olivier Berger wrote: It's about upgrading the data (i.e. the standard set of pages, the preferences, the templates, all kind of stuff that twiki uses in order to work well, beyond the scripts). /var/lib/twiki/templates is correctly managed by dpkg and there shouldn't be an automatic merge of local changes for the standard set of files. Instead of changes to these files one should have set up a custom skin. Probably right... unless there is something changed on runtime into templates/ by twiki... I don't know enough about how templates work in twiki to say for sure. For the debian package UpgradeTwiki should not handle anything but /var/lib/twiki/data/... and the conffiles (that's all it does I think). That should be ok with dpkg as it does not manage /var/lib/twiki/data/... Yep. But anyways, this will require a human intervention at all cases... and a bit of understanding of a diff/merge tool. What's wrong about running it from postinst on upgrade? From my experience in using it in a recent upgrade, there were unresolvable conflicts that needed to taken care of... as it may involve the security of the webs, for instance in case of variables like ALLOWxxxCHANGES, I think it is wise to let the admin of the twiki do the work. That's a bit tricky since much of twiki's configuration is done in its data... not so good for an application which sould be upgradable automatically :( I think the first step is to add it to the package (or a similar tool, only dedicated to the data), and see how it goes with the Debian users... In any case, once you setup a complex and fairly customised twiki, it may be wise not to use the Debian package but a custom installation ? ;) My 2 cents. Best regards, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295497: twiki: bin/gnusave bug (patch included)
Frank, i don't think gnusave is part of the twiki package. are you fixing bugs in the gnu skin? in which case they need (at least for now) to be reported and fixed upstream Sven On Wed, 2005-02-16 at 15:49 +0800, Frank Horowitz wrote: Package: twiki Version: 20040902-1 Severity: important Tags: patch The bin/gnusave routine missed an intermediate step in it's path to decodeSpecialChars(). Patch attached. I'm still seeing other problems though in new install. If I find and fix them, I'll follow up with another bug report. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27-2um Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages twiki depends on: ii apache2-common2.0.52-3 Next generation, scalable, extenda ii debconf 1.4.30.11 Debian configuration management sy ii libalgorithm-diff-perl1.19.01-1 a perl library for finding Longest ii libdigest-sha1-perl 2.10-1 NIST SHA-1 message digest algorith ii perl [libmime-base64-perl]5.8.4-6Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.4-6Core Perl modules ii rcs 5.7-14 The GNU Revision Control System -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292474: twiki plugins should come from /usr/local/twiki/lib
Package: twiki Version: 20030201-6 you should be able to unpack plugins in /var/lib/twiki This has been working for me with version 20030201-6 on Sarge (testing). I think the way to best match what other Debian packages do would be to have TWiki look in /usr/local for locally-installed templates, plugins, etc., but I understand that this may be a big change from the upstream code. It would be nice to just be able to unpack in e.g. /usr/local/twiki as a member of group staff rather than in /var/lib/twiki (with its links to /usr/lib/cgi-bin/twiki and /usr/share/perl5) as root. Using /usr/local avoids any system pollution, keeping locally-installed bits out of dpkg's way. -- VineetKumar - 27 Jan 2005 -- Vineet - I like the idea, and have added it to twiki's bugs list This idea unfortunatly will not really work for anything other than lib files at the moment, but I think the idea has considerable merit even when taking the effort required into consideration Cheers Thanks for the idea Sven -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
