-----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 PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
