[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:
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
---------------------------------------