Re: Vulnerability and Patch Information
Podo, Around here I have had to write up exception documents for our OpenBSD servers when we get stuff like this on security audit/scans. Imagine the pain in the ass it is to have to convince a non-technical supervisor that the HIGH LEVEL vulnerability (that in one case only effected Debian Linux) was already fixed on OpenBSD years before it was ever discovered, and then figure out how to put it all on paper in an intelligent way. I have found that by looking on sites like security focus for the list of which systems are effected by a given vulnerability and crossing that with the OpenBSD patch download pages for current and previous versions I can usually find where there was a patch that fixed a given vulnerability. It is a bit of work and isn't easy, but it is do-able. This is all made easier in my case because I keep my servers running as close to the base install as possible only adding additional software when I have to because the base install doesn't provide a service or the service it provides doesn't have all the options I need. Then I really look hard to see if I really need that particular option before I look at other software. Happily, my boss gives me some leeway on choosing how to set things up. I have one firewall that is on an external audit/scan list that the people who actually do our audits doesn't believe really even exists because they can't even find it. Basically it has EVERYTHING locked down tight as a drum and allows only a few things through to and from very specific places. I love to show the blank audit page to the boss, esp. just before bonus time. Thanks so much to the OpenBSD project for making me look so good. stuart
Re: Vulnerability and Patch Information
On 18/10/06, stuartv [EMAIL PROTECTED] wrote: I have one firewall that is on an external audit/scan list that the people who actually do our audits doesn't believe really even exists because they can't even find it. Basically it has EVERYTHING locked down tight as a drum and allows only a few things through to and from very specific places. Just a curious guess: Is that box a packet filtering bridge with two NICs and no IP addresses assigned? On a related note: Does anyone have an educated guess on whether it's possible to OS-fingerprint such bridges? (It shouldn't be, right?)
Re: Vulnerability and Patch Information
Podo Carp wrote: Thanks Steve, The scanner does indeed rely on banners (which can be completely unreliable especially on OpenBSD). However, I would like them to not knock over my servers trying to confirm the problem if I can easily determine that the patches are irrelevant. Of course this is a greater problem for holes that are not fixed but I can't tell which is the case without more information. A centralized repository of vulnerability information would make my job maintaining OpenBSD systems much simpler and would provide yet another avenue to extoll the virtues of OpenBSD versus other operating systems (as in this case where the patch was released a year before the vulnerability was disclosed). You can find all security vulnerabilities here: http://www.openbsd.org/errata.html
Re: Vulnerability and Patch Information
On Wed, Oct 18, 2006 at 05:09:12PM +0200, ropers wrote: On 18/10/06, stuartv [EMAIL PROTECTED] wrote: I have one firewall that is on an external audit/scan list that the people who actually do our audits doesn't believe really even exists because they can't even find it. Basically it has EVERYTHING locked down tight as a drum and allows only a few things through to and from very specific places. Just a curious guess: Is that box a packet filtering bridge with two NICs and no IP addresses assigned? On a related note: Does anyone have an educated guess on whether it's possible to OS-fingerprint such bridges? (It shouldn't be, right?) I can imagine that different OSes might react in different way to malformed packets; this could also apply to L2, and would likely be noticeable on bridges using L3 filtering (i.e., pf). Of course, this is not a practical answer. Joachim
Re: Vulnerability and Patch Information
Hi Joe, I see that some errata information has CVE included (probably those disclosed before OpenBSD fixed them). Where this information is absent, I am not confident that the errata details are relevant. In the case of the SSL problem, there was a patch released around the time of the original CVE creation which modified ssl_engine_log.c (where the relevant fix was made) but which fixed a different issue. Many UNIX administrators do not have the technical skills required to identify which bits of corrected code fix which problems. Simplifying the process of locating vulnerability information would, therefore, make OpenBSD a more attractive option to a wider audience and help ardent OpenBSD advocates sell the solution to managers and executives who may not fully appreciate the advantages of OpenBSD. I love the fact that OpenBSD does not compromise the fundamental security and design principles upon which it was founded. Adding clearer documentation of OpenBSD's superior security can only enhance its reputation. Cheers, Dan On 10/19/06, Joe [EMAIL PROTECTED] wrote: Podo Carp wrote: Thanks Steve, The scanner does indeed rely on banners (which can be completely unreliable especially on OpenBSD). However, I would like them to not knock over my servers trying to confirm the problem if I can easily determine that the patches are irrelevant. Of course this is a greater problem for holes that are not fixed but I can't tell which is the case without more information. A centralized repository of vulnerability information would make my job maintaining OpenBSD systems much simpler and would provide yet another avenue to extoll the virtues of OpenBSD versus other operating systems (as in this case where the patch was released a year before the vulnerability was disclosed). You can find all security vulnerabilities here: http://www.openbsd.org/errata.html
Re: Vulnerability and Patch Information
Podo Carp wrote: I love the fact that OpenBSD does not compromise the fundamental security and design principles upon which it was founded. Adding clearer documentation of OpenBSD's superior security can only enhance its reputation Are you volunteering to do the work? --- Lars Hansson
Re: Vulnerability and Patch Information
Touche! I can contribute several hours a week to this effort with the caveat that I wasn't too successful in finding the original fix which spawned this thread. Cheers, Dan On 10/19/06, Lars Hansson [EMAIL PROTECTED] wrote: Podo Carp wrote: I love the fact that OpenBSD does not compromise the fundamental security and design principles upon which it was founded. Adding clearer documentation of OpenBSD's superior security can only enhance its reputation Are you volunteering to do the work? --- Lars Hansson
Vulnerability and Patch Information
Greetings, I recently underwent an audit of my OpenBSD 3.8 systems and the audit report identified CVE-2004-0700 (mod-proxy/mod_ssl format string vulnerability) as a potential risk. Given the age of the problem and the proactive patching stance of OpenBSD, I suspect this has been fixed for some time. However, I can't find any reliable information correlating CVE or other general vulnerability records with a specific OpenBSD patch or fix. I have searched the mailing list archives for both security announcements and code updates but have not found any conclusive documentation indicating this vulnerability is not relevant or was fixed. Does OpenBSD provide any authoritative reference as to which vulnerabilities are corrected by which patches? What is the most effective way to find this information if no such reference exists? I apologize if this question has been answered elsewhere. I have spent some time searching with no success. Cheers, Dan
Re: Vulnerability and Patch Information
Podo Carp wrote: I recently underwent an audit of my OpenBSD 3.8 systems and the audit report identified CVE-2004-0700 (mod-proxy/mod_ssl format string vulnerability) as a potential risk. Perhaps your scanner relies on reported versions, rather than actual vulnerabilities? If I'm reading the vulnerability right, it was fixed here: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_ext.c.diff?r1=1.9r2=1.10f=h The vuln was disclosed 7/27/2004, but was fixed 6/1/2003.
Re: Vulnerability and Patch Information
Thanks Steve, The scanner does indeed rely on banners (which can be completely unreliable especially on OpenBSD). However, I would like them to not knock over my servers trying to confirm the problem if I can easily determine that the patches are irrelevant. Of course this is a greater problem for holes that are not fixed but I can't tell which is the case without more information. A centralized repository of vulnerability information would make my job maintaining OpenBSD systems much simpler and would provide yet another avenue to extoll the virtues of OpenBSD versus other operating systems (as in this case where the patch was released a year before the vulnerability was disclosed). I understand that correlating patches with as yet undisclosed or unidentified flaws is not possible. However, whenever a security vulnerability is announced, every administrator should be asking themself if their systems are vulnerable (even if they have tremendous confidence that OpenBSD would normally handle such problems proactively). Answering that question (as you have kindly answered for me) would be a normal part of the review process and documenting the result would be very beneficial to the OpenBSD community. Cheers, Dan On 10/18/06, Steve Shockley [EMAIL PROTECTED] wrote: Podo Carp wrote: I recently underwent an audit of my OpenBSD 3.8 systems and the audit report identified CVE-2004-0700 (mod-proxy/mod_ssl format string vulnerability) as a potential risk. Perhaps your scanner relies on reported versions, rather than actual vulnerabilities? If I'm reading the vulnerability right, it was fixed here: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_ext.c.diff?r1=1.9r2=1.10f=h The vuln was disclosed 7/27/2004, but was fixed 6/1/2003.
