Security [LWN.net]

A new set of OIS vulnerability guidelines

The Organization for Internet Safety has announced the availability, in draft form, of its "Security Vulnerability Reporting and Response Guidelines." These guidelines offer suggestions for how security researchers and software vendors should work together to deal with security problems in the most effective way. Comments are being solicited for this version; they will be accepted until July 16.

The guidelines, for the most part, make sense. Essentially, they say that things go as follows:

A researcher finds a problem.
That problem is communicated in a clear way to the relevant vendor.
The vendor responds, and the two agree on a timeline for investigating the problem and, if warranted, developing a fix.
The two talk to each other while this is going on.
When the fix is complete, the vendor makes it available, and both parties can release advisories.
Detailed information on the vulnerability is to be withheld for 30 days.

Of course, it takes the OIS 23 pages, many dozen sub-objectives and contingencies, and several complicated flow charts to communicate the above.

The OIS and its guidelines have come under significant fire recently. Many people distrust the OIS after having seen its list of members: @stake, BindView, Foundstone, Guardent, ISS, Microsoft, NAI, Oracle, SGI, Symantec, and our old friends the SCO Group. There are no independent researchers: OIS policy explicitly excludes them. There is also no representation from the free software community. In fact, the OIS is not that impressed with free software in general:

We believe the software author should be given a chance to create a fix before vulnerability information is made public, but that there should be no further distribution of that information until the fix is complete. This priniciple [sic] can be very difficult to adhere to in certain situations, such as dealing with the open source community where there aren't protections to keep vulnerability information secret.

In recent times, the community has shown itself to be quite capable of keeping vulnerability information under wraps for the time it takes to generate a fix. If you want to do that, though, it is imperative to create the fix quickly. The vendor-driven OIS standards seem more oriented toward keeping vulnerability information secret for as long as possible.

The OIS claims that it has no intention of promoting legislation which would codify its guidelines. Given the nature of some of the companies involved, not everybody believes that claim. Certainly any attempts in that direction should be watched for and resisted.

Perhaps the most interesting perspective on the OIS is this, however: there are no free software organizations or vendors represented because the community has no need for the OIS. As a general rule, vulnerability reporting and response works very well in the free software world. Vulnerabilities are reported to the relevant parties, and a whole set of independent vendors and projects gets fixes out quickly. It is hard to see problems in this aspect of our performance which are amenable to any sort of improvement via a set of official guidelines. Our problems, instead, lie in the fact that we create far too many vulnerabilities in the first place. The OIS is not going to help us with that.

Security

A new set of OIS vulnerability guidelines

esearch: insecure temp file handling

kernel allows unauthorized changes to the group ID

Pure-FTPd - denial of service

XFree86, X.org: XDM ignores requestPort setting

Apache mod_proxy: denial of service

apache2: stack-based buffer overflow in ssl_util.c

Apache: denial of service

aspell: bounds checking problem

dhcp: buffer overflows

Filename disclosure vulnerability in fam

flim: insecure file creation

FreeS/WAN, Openswan, strongSwan: Vulnerabilities in certificate handling

giFT-FastTrack: remote denial of service attack

gtkhtml: malformed messages cause crash

gzip: temporary file execution problem

Horde-IMP: improper input validation

iproute: local denial of service

racoon: failure to verify signatures

racoon: denial of service vulnerability

kdelibs: cookie disclosure

kernel: symlink overflow in the iso9660 filessytem

kernel: netfilter denial of service

kernel: denial of service

kernel-utils: setuid vulnerability

krb5: unauthorized root privileges

libpng, libpng3: buffer overflow

libxml2 - arbitrary code execution

logcheck: symlink vulnerability

mailman: password disclosure

mikmod: buffer overflow

mod_python: denial of service vulnerability

mozilla: multiple vulnerabilties

mpg321: format string vulnerability

MySQL: temporary file vulnerabilities

neon: buffer overflow

Nessus NASL scripting engine security issues

netpbm: insecure temporary files

openssh: timing attack leads to information disclosure

OpenSSL: denial of service vulnerabilities

pavuk: buffer overflow

postgresql buffer overflow in ODBC driver

python: buffer overflow

rsync remote file write attack

squid: buffer overflow

SquirrelMail cross site scripting vulnerabilities

Subversion: Remote heap overflow

sysstat: temporary file vulnerability

File overwrite vulnerability in tar and unzip

tcpdump: ISAKMP payload handling denial-of-service vulnerabilities

Multiple vendor telnetd vulnerability

tripwire format string vulnerability

webmin: denial of service

XChat 2.0.x SOCKS5 Vulnerability

xine-ui - insecure temporary file creation