-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDQoQ49n4qXRzy1ioRAq3qAJ0Unv67KRVRhspysHwYVSPMcgREXQCgnErl dQYbLhUMHN1nVASNCDzWAew= =Ew1E -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
