Archive for the ‘Security’ Category
When you give your customers the list of “vulnerabilities” to take up with their vendor, can you please make sure of a couple of things?
- Actually identify the security vulnerability with a reference so we don’t have to try to interpret your vague description of it (a pointer to one of the sites that reports security vulnerabilities isn’t that hard is it?)
- Verify that the system really is vulnerable. As I pointed out in an earlier blog, looking at the version label is not always enough to say that a version is vulnerable. Let alone the fact that sometimes even the best of tools get false positives.
One call I have been dealing with over the last few days identified that a customer was vulnerable to five different items. After working out what was really meant by three of them I was able to determine that they were vulnerabilities that we put patches out for back in 2003 and the customer had patches on the system that included these fixes. If the scanner software had probed the vulnerability it would have seen the product in question safe. Of the other two, “rexec” was commented out of /etc/inetd.conf and netstat -a showed nothing listening on port 512, and they actually did still have rshd running, which they needed to turn off.
Because of the vagueness of the descriptions I was given I had to spend quite some time researching three of those vulnerabilities to find exactly what they meant (not helped by how old they were).
You can probably imagine how pleased I was at having to spend time doing this research when I have other calls in my queue that really also needed attention, only to find out that it could all have been avoided.
I had a few support calls today and yesterday with folks asking us about their scanners reporting:
Found the PWS-SPyEye!env.a trojan !!!
against a lot of different files on Solaris ranging from database install executables to parts of a python patch.
I found a thread on the McAfee community site discussing this. It wasn’t only Solaris that was having the problem. There were a few people who had run tests against files which had not been modified (and stored on DVD) from before the time that this trojan hit being reported as vulnerable.
I had another look this morning and it appears that these reports only occur on version 6282 of the virus definitions file and that todays file (version 6286) no longer shows these files as hits.
Before logging an Oracle support call if you see this, could you try updating the virus definitions file to at least version 6286?
Kudos to McAfee for sorting this out quickly.
This is a blog posting with a bit of self-interest attached. The self interest being to try to save myself some unnecessary support call handling.
You may have seen the Sun Security blog addressing the CVE-2010-1452 mod_dav Vulnerability in Apache 2.0.x HTTP Server issue.
The patches that this blog points to mention in the README
6972023 upgrade httpd to 2.2.16 (CVE-2010-1452, CVE-2010-2068)
This bug synopsis is misleading. The patch does not actually upgrade httpd to 2.2.16. What it does is to backport the fixes for the CVEs mentioned. The patch README should be shortly updated to make this clearer.
Now, that being said you may also note after installation that it still identifies as Apache 2.0.63 and you may have concerns about vulnerabilities addressed in 2.0.64 mentioned on the Apache web site.
The way that we maintain Apache on Solaris 10 is not to drop in new releases as they happen, rather we take the fixes mentioned and backport them to our 2.0.63 codebase.
Inside the patch are two files called README.sfw.
If you have the Apache source product installed these files will be installed/updated on your system. If you do not, the files will still be present in the actual patch and you can find them under one of the
reloc directories. At the end of these files we document which fixes have been backported.
Please consult these files before logging support calls asking questions of the form “Is your version of Apache is vulnerable to …?”