[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Calysto v1.5 reports on openldap_v2.4.4alpha

Speaking as an individual participant in the OpenLDAP Project...

On Aug 21, 2007, at 1:00 AM, Pierangelo Masarati wrote:

Domagoj Babic wrote:

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.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it