CVE-2008-3886 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3886): Multiple cross-site scripting (XSS) vulnerabilities in index.php in dotProject 2.1.2 allow remote attackers to inject arbitrary web script or HTML via (1) the inactive parameter in a tasks action, (2) the date parameter in a calendar day_view action, (3) the callback parameter in a public calendar action, or (4) the type parameter in a ticketsmith action. CVE-2008-3887 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3887): Multiple SQL injection vulnerabilities in index.php in dotProject 2.1.2 allow (1) remote authenticated users to execute arbitrary SQL commands via the tab parameter in a projects action, and (2) remote authenticated administrators to execute arbitrary SQL commands via the user_id parameter in a viewuser action.
mailed upstream
Adam Donnison (upstream) wrote: We are aware of these issues and have taken steps to resolve them. The nightly snapshot (http://dotproject.sourceforge.net/dotproject-stable_2.tar.bz2) contains fixes for all but the ticketsmith issue. Ticketsmith was not written by the dotProject team, and is no longer maintained and will be dropped from the release and moved to the optional modules project dotmods. At this stage we do not have a date for a release which includes these fixes.
As upstream is unable to provide a security release I masked the package. It would probably be possible to generate a patch set but somebody would have to provide that in order to unmask it again.
Even though I don't agree with what seems to be the trend of late ... hard masking package builds for every little security vulnerability which pops up ... could you at least make the hard mask a stable one? Masking it twice over is redundant if not inaccurate (the package build isn't unstable) and a pain for users to unmask otherwise. Aside from the vulnerability listed the code is otherwise stable. As stated by Adma, the fixes are available in the nightly snapshot. Also as noted, the "ticketsmith" module is not supported and will be dropped from the next release. Also, Gentoo devs can always map to the nightly snapshot given to provide a "live" dotProject ebuild for its users.
@Matthew: Stabilizing a hard masked package is not at all possible. "Stable" means stable from the viewpoint of Gentoo *not* from the viewpoint of the project itself. "Stable" for us has a crucial meaning for security: We promise our users a short reaction time on stable packages. So what you propose is really against our policies (http://www.gentoo.org/security/en/vulnerability-policy.xml) in many ways. As visible from your e-mail you are working on dotproject: I'd like to kindly ask you and your team to review your security policies. I'm a PHP developer myself and anyone on a project team that would consider a security release to be negligible after a vulnerability was found would get a harsh treatment from me and would be sent to a security workshop. As long as you only have a few users toying around with your software it may be okay to ignore security but once usage increases or you want to move into business areas then security release are not a debatable point.
Policy must have changed of late then in Gentoo as far as hard masking packages (as opposed to arch masking them). It was my understanding from that hard-masked packages were equivalent to any software package which could quite easily crash/break during normal, everyday operation and that arch-masked masked packages were possibly stable but had not been tested enough yet, or had other less serious issues they could be considered stable. (paraphrasing from http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#masked ) As far as the documentation at link you gave, I can really only see one instance where anything is mentioned about masking a package: "if no upstream fix is available (upstream+ status), a decision must be taken on masking the package: the security team can mask a package which is not depended on by itself, but need a TLP manager approval before masking a package which is not standalone" However, I'm not sure what sort of "mask" it refers to as it's not spelled out (could be interpreted as either arch-masked or hard-masked). As for our "security policies", we do take security seriously and have made releases shortly after fixing major security bugs, but don't necessarily make a point of releasing for every lesser issue/bug that comes along. I say lesser concerning this issue mainly because the vulnerability at hand only applies to users with valid login credentials (and in one case only valid users with administrative credentials), otherwise it would be a major concern if just anyone could inject the malicious code from anywhere and we would have made it a point to make push out new version for the purpose of security. As noted, there is a fix available in the nightly snapshot of the stable branch of our Subversion repository (available at http://dotproject.sourceforge.net/dotproject-stable_2.tar.bz2 ), it's just not a fix that is in a neatly package and versioned bundle. If I post a patch to upgrade our the last release to the current state of our stable branch, could it be easily worked into a new ebuild to reflect the security changes? Finally, for further reference, the "original" posting of this advisory (of which we were *not* directly informed of previous to posting, major faux pas in my personal opinion) can be found at http://secunia.com/advisories/31681/
P.S. Please excuse my occasionally broken grammar. I neglected to proofread (it's what I get for writing in code-like blocks). Please note the following "corrections" to clarify possible ambiguities: ... or had other less serious issues (they would otherwise be considered stable) ... to upgrade our last release to the current state of our stable branch
(In reply to comment #6) > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=1#masked "package.mask means that the package has been found corrupt, unstable or worse and has been deliberately marked as do-not-use." Actually security issues are "worse" and we deliberately mask security packages as do-not-use. > However, I'm not sure what sort of "mask" it refers to as it's not spelled out > (could be interpreted as either arch-masked or hard-masked). Probably wording could be improved but in this case hard masking is meant. ~arch masked packages are not broken packages - they are just not tested enough. Broken and vulnerable packages should be package.masked (or hard masked). > As for our "security policies", we do take security seriously and have made > releases shortly after fixing major security bugs, but don't necessarily make a > point of releasing for every lesser issue/bug that comes along. I say lesser > concerning this issue mainly because the vulnerability at hand only applies to > users with valid login credentials (and in one case only valid users with > administrative credentials), otherwise it would be a major concern if just > anyone could inject the malicious code from anywhere and we would have made it > a point to make push out new version for the purpose of security. Any security issue worth new release and policy just dictates time frame to fix the issue. This is not our policy but policy in any distribution I'm aware about. The only change that happened recently in Gentoo was not policy but lack of developers in www-apps herd so we don't have enough time to dig patches and patch our packages. So in case upstream has no new fixed release in reasonable time frame or stated that they are not going to update latest release - we package.mask such packages. Hard-masking does not fix the problem but ensures that our users are aware about this problem since package.mask entry contains bug number and users will find description of the problem. At last we are community distribution so in case users really need this package they could help us and dig patches or provide some fix we could apply in the tree. At the same ~arch masked packages are not broken or vulnerable packages. ~arch masked packages are those that were not enough tested. From security point of veiw ~arch does not mean that we should not fix security issue (we still have security bugs for ~arch packages) it just means that we have much longer time to fix issue and no glsa will be issued after fix. > If I post a patch to upgrade our the last release to the current state of our > stable branch, could it be easily worked into a new ebuild to reflect the > security changes? Sure. Thanks for your valuable input and I hope I've managed to explain why we hard-masked this package.
Matthew, if you want to help here, encourage upstream to package their current stable branch into a new release. They confirmed fixing this issue in September, but lack a release of their code since then. You can also dig through their CVS log and try to find the patch that fixes these issues. To do that, look at the CVE references I linked to in comment 0.
(In reply to comment #8) > "package.mask means that the package has been found corrupt, unstable or worse > and has been deliberately marked as do-not-use." > > Actually security issues are "worse" and we deliberately mask security packages > as do-not-use. > Ok, that makes some sense. Though it would be nice if you had the capability better specify through portage some sort of package.mask sub-type (e.g. "crash", "security", etc.) as well as a severity level (say crashing half the time when using an experimental feature would be lower severity than a program that crashes 90% of the time just when loading or operating "normally" > Probably wording could be improved but in this case hard masking is meant. > ~arch masked packages are not broken packages - they are just not tested > enough. Broken and vulnerable packages should be package.masked (or hard > masked). > Agreed given previous explaination. > Any security issue worth new release and policy just dictates time frame to fix > the issue. This is not our policy but policy in any distribution I'm aware > about. The only change that happened recently in Gentoo was not policy but lack > of developers in www-apps herd so we don't have enough time to dig patches and > patch our packages. So in case upstream has no new fixed release in reasonable > time frame or stated that they are not going to update latest release - we > package.mask such packages. Hard-masking does not fix the problem but ensures > that our users are aware about this problem since package.mask entry contains > bug number and users will find description of the problem. At last we are > community distribution so in case users really need this package they could > help us and dig patches or provide some fix we could apply in the tree. Again, understandable, I guess, given the masking options. > > At the same ~arch masked packages are not broken or vulnerable packages. ~arch > masked packages are those that were not enough tested. From security point of > veiw ~arch does not mean that we should not fix security issue (we still have > security bugs for ~arch packages) it just means that we have much longer time > to fix issue and no glsa will be issued after fix. > I can definitely sympathize with lack of time/people/resources. Seems to happen to every OSS project at some point that's not commercially supported (and even sometimes some that are). > > If I post a patch to upgrade our the last release to the current state of our > > stable branch, could it be easily worked into a new ebuild to reflect the > > security changes? > > Sure. I'll see about doing a diff of the revision in our stable branch where this was fixed against the tag of our last release. > > Thanks for your valuable input and I hope I've managed to explain why we > hard-masked this package. > Thank you for your detailed explanation of the current masking process. It helped to shed some light on details which were not clear i the available documentation. (In reply to comment #9) > Matthew, if you want to help here, encourage upstream to package their current > stable branch into a new release. They confirmed fixing this issue in > September, but lack a release of their code since then. You can also dig > through their CVS log and try to find the patch that fixes these issues. To do > that, look at the CVE references I linked to in comment 0. > Well I'm definitely in the position, since I'm on the maintenance team ;-) (thus the dotproject.net email addy), but there's still a handful of known bugs to investigate/squash before we could be in a good position to do a minor release (that and also have to go though our release testing once they're resolved).
Created attachment 178296 [details, diff] diff to update dotProject 2.1.2 to current stable branch Version 2.1.2 of dotProject was tagged as of revision 5791. The current revision level is 5840.
Matthew, sorry I did not notice the email address. :-) Does the patch you attached introduce those bugs you mentioned, or do you consider it safe to apply? If so, I'd ask web-apps to include it in a revbump.
(In reply to comment #12) The issues reported are likely ones that were there in the 2.1.2 release but were just "uncovered" recently and as such I would consider it safe to apply. As far as remaining reports go, I still have about half of them to actually go through (roughly 10) and verify that they are, in fact, still an issue in the latest stable code. It since more often than not it seems that users will only fetch the major release packages (i.e. won't check for interim version fixes) and won't search the bug forums thoroughly enough to see if their particular issue has been resolved or closed. In many cases, the "issue" was actually due to an error in configuration on their server, but they always (of course) assume it's something wrong with the software without even checking for other points of failure (I've seen my share of these particularly concerning email notifications not getting sent). Mini rant aside, what reports there are yet to be resolved relating to bugs are only a handful and relatively minor ones, but in the mean time until they can all be resolved and we can get the next bug-fix release out, this is as good a revbump point as any until then.
Well, I've added patch and unmasked package. It has not stable version at this moment (stabilization will be in a month is users request that), so this bug can be closed now.
Yep, thanks.
