Speaking as an individual participant in the OpenLDAP Project...
On Aug 21, 2007, at 1:00 AM, Pierangelo Masarati wrote:
Domagoj Babic wrote:
Pierangelo,
I didn't understand the last part on marking submissions private. Pardon my ignorance. Could you please elaborate?
Please keep replies on the list.
For this purpose, the ITS allows to mark submissions as PRIVATE.
You posted to the openldap-bugs mailing list.
Which I think is the right place to start with such reports. His message indicated he wanted to discuss potential bugs.
This list is for discussion about bugs; but to track issues, like a bug report (as yours seems to be) you're supposed to file an ITS using the ITS interface http://www.openldap.org/its/. This is necessary to keep track of the status of your submission, otherwise it's just a bunch of emails, eventually destined to the bin.
I rather not flood ITS with potential bugs.
I rather the potential bug list be discussed on -bugs first and upon determining there is a signficant bug, reporting that bug as an ITS, preferably with patch.
When you submit a bug, you can mark it as PRIVATE.
If the its a "major security issue". If one detects a buffer overrun condition, that would be reasonable to report as a major security issue. However, a simple crash (deref NULL) is not.
This means that the bug will only be visible to authorized users (essentially, OpenLDAP developers). A PRIVATE ITS means it's only temporarily private, until the issue is solved; after that, all the traffic about that ITS becomes public. This feature is solely intended to deal with issues that may potentially represent a threat to data security, or system vulnerabilities.
If the original report would have been filed as a "major security issue", I suspect it would have been rejected as not being indicative of a major security issue. Also, it inappropriate to file multiple issues in one report. If there is some particular major security issue, it should be filed separately.
And given the nature of these kinds of issues, there is really no point in keeping them private. We should assume attackers have static checking tools. We should assume such issues are public knowledge.
And even if they were filed as private, it truly a major security issue, it would in all likelihood be fixed immediately. Once fixed, the private flag would be lifted. This would happen so fast for most every issue discovered via static checking making the private flag pointless.
That is, the private flag should only be sit with the issue is truly a major security issue AND it likely that issue will not be fixed immediately.
For example, if your static scan just checks for NULL pointer dereferencing, without considering the context, as Kurt and Howard already pointed out you could find that hundreds of occurrences that a test client does not check malloc(3) results without being harmful, and one occurrence of the server not checking a pointer at the culprit of dealing with requests. In the latter case, until fixed this would expose all deployments of OpenLDAP to denial of service, but it could go unnoticed because clobbered by the rest.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it