Yet another “Month of..” bug campaign. This time, the Month of ActiveX Bugs (MoAxB) will focus on vulnerable ActiveX controls. Do a quick title search for “activex” and you will see a healthy history of vulnerabilities related to ActiveX controls. There is already a debate on the Full-Disclosure list regarding if this will be a month of annoying Denial of Service issues, or something more severe.
I previously blogged about the Month of PHP Bugs [MOPB], an effort lead by Stefan Esser and the Hardened PHP Project to raise awareness about vulnerabilities in the PHP language. The month has come and passed and of course I have to wonder about a few things.
1. The project ended up releasing 45 vulnerabilities over 31 days, many of them remotely exploitable. For anyone that was under the delusion that PHP was “pretty secure”, think again. Not only were some remote, many were methods for bypassing the native protection methods PHP offers like open_basedir or issues with various functions designed to filter bad input.
2. These “Month of X Bugs” always get a press blitz before it happens, but we rarely see the same news outlets cover the same thing a month later. It’s nice to see the results of the project, the number and type of vulnerabilities as well as any insights (see comments on previous blog post) the developers had.
3. The PHP project thankfully responded to many of these vulnerabilities already. PHP 5.2.1 and 4.4.5 fix a lot of security issues. Oh wait, that was released two weeks before the MOPB. Where is the next big release that fixes the unpatched issues?
All in all, a very impressive effort. Esser and the Hardened PHP Project have certainly raised the bar for the “Month of X Bugs” projects.
A Month of Rixstep Bugs
It’s a win-win proposition.
Starting now and for the duration of January 2007 Rixstep will be holding a ‘Month of Rixstep Bugs’ campaign: find a bug in any Rixstep software product and win a prize.
It’s not a win-win proposition, it is a lame gimmick. After the month of apple bugs, week of (cancelled) oracle bugs, and the month of linux kernel bugs, Rixstep wants in on the bandwagon. Few small problems:
- They posted this announcement on the 4th, not even giving a full month.
- They didn’t post this to Bugtraq, Full-Disclosure, or any other security list/resource I monitor.
- Rixstep doesn’t have the saturation that Linux, Apple or Oracle do. It is considerably easier to test those products and platforms versus Rixstep, who many of us have never heard of, let alone seen deployed.
If you want to play with the big boys Rixstep, man up and put some of your products up on your site and post the challenge to Bugtraq and Full-Disclosure.
Tonight I went shopping with my wife as she wanted to purchase a new 2007 day planner. She was looking through all kinds of different types and really could not make her mind up about which one was the best. Finally, I decided to start looking at them as well so I could help her pick one out. I grabbed this pink leather Franklin Covey planner and started flipping through the pages. It had all of the typical things that you expect in an organizer. It also had random pages for you to write down your important contacts, birthdays, phone numbers, notes… and passwords! There was a full page included with this planner for you to write down and help you organize your account names and passwords.
With computers and the Internet becoming so mainstream it makes sense why things like this are starting to be introduced into everyday products. However, it drives me nuts– it goes back to the on-going security awareness debate and determining how much effort you put into training people not to write down their passwords, etc. It is hard enough to get most people to think about security but it makes it even worse when companies produce products that encourage people to be insecure!
I can see it now… people stealing day planners to get usernames and passwords.
I previously blogged about the SANS Top 20 List in a pretty negative fashion. The list started off as the “Top 10 Vulnerabilities” and quickly expanded into the Top 20 Vulnerabilities. Even last year (2005), they were still calling it a “Top 20 Vulnerabilities” list when it clearly had become anything but that. This year, SANS finally wised up calling the list “SANS Top-20 Internet Security Attack Targets”. Yes, they are now listing the 20 most attacked ‘targets’, not ‘exploited vulnerabilities’. With this change, does the list regain some of the value it originally had and quickly lost? Let’s look at the list:
W1. Internet Explorer
W2. Windows Libraries
W3. Microsoft Office
W4. Windows Services
W5. Windows Configuration Weaknesses
M1. Mac OS X
U1. UNIX Configuration Weaknesses
C1 Web Applications
C2. Database Software
C3. P2P File Sharing Applications
C4 Instant Messaging
C5. Media Players
C6. DNS Servers
C7. Backup Software
C8. Security, Enterprise, and Directory Management Servers
N1. VoIP Servers and Phones
N2. Network and Other Devices Common Configuration Weaknesses
Security Policy and Personnel
H1. Excessive User Rights and Unauthorized Devices
H2. Users (Phishing/Spear Phishing)
Z1. Zero Day Attacks and Prevention Strategies
So if you run Windows, Unix, or MacOS .. and/or have Web Applications, Database software, allow P2P file sharing, allow IM messaging, have media players (installed by default on most OSs), run DNS servers, run Backup Software, run Security/Enterprise/DM servers .. and/or use VoIP servers/phones or “network and other devices”.. and/or have weak policy governing user rights or don’t prohibit certain devices and you actually have users.. you have at least one of the “Top 20 Attack Targets”. Wow, is that ever so helpful. Oh, I forgot, failing all of that, “Zero Day Attacks” are a top 20 attack vector.
Hey SANS, could you make a more overly vague and general security list next time? Maybe for 2007 you could shorten it from the “Top 20” to the “Top 1” and just list “C1: Have a computer type device”. That would save your analysts a lot of time and be just as helpful to the masses. Seriously, ditch the list or go back to the basics.
Oracle’s last quarterly critical patch update included some changes and started using CVSS to rate the severity of their vulnerabilities. Anyone that has ever tried to truly understand Oracle vulnerabilities most likely thought this would be a much needed improvement. The whole easy, difficult, wide, low, high ratings Oracle used previously made it almost impossible to figure out just how critical are the issues and then to prioritize the patch implementation.
Shortly after the October CPU was released, researchers started to question the CVSS ratings leading many to believe that Oracle is downplaying the true risk of the vulnerabilities.
Oracle also patched 13 remotely exploitable holes in its Application Server software, the highest of which the vendor rated as 4.7 out of 10. However, a closer examination of the flaws suggest that many of the ratings should be in the 8.0 range, said Caleb Sima, CTO of SPI Dynamics, an Atlanta-based security vendor that also reported bugs to Oracle. “The problem is, Oracle didn’t give enough details [for third parties] to be able to say exactly what the score should be,” Sima said. – Source
Oracle claims that they are listening to their customers and trying to help organizations really understand the true risk. However, it appears that for many of the vulnerabilities there contained even less detail with the new format than previously. Was the only real improvement to the advisories that questionable CVSS ratings were included?
This entry should have been published days ago. On top of being overly busy and spread thin, I ran into a big problem related to finding a reference I wanted to include, which will lead to this being a little more ranty than intended.
How is it that our industry is over twenty years old (don’t bother debating how old the ‘security’ industry really is), and we don’t have a list of commonly accepted vulnerability classifications? Traditionally, it was fairly easy to list out the major classifications; overflow, symlink, race condition, command injection, XSS, SQL injection, path disclosure, traversal, denial of service, format string, etc. Over time we saw new types of vulnerabilities like HTTP Response Splitting, CRLF injection, Off-by-one, Underflows, etc. So, who keeps a list of what constitutes a class of vulnerability? The Secure Software Body of Knowledge has nothing, SANS’ glossary doesn’t even appear to have cross site scripting, and the OWASP Top Ten is a bit too high level. The best resources are probably:
- The OWASP Vulnerability Listing but I think this is too detailed to cover a general classification breakdown.
- Mitre’s Common Weakness Enumeration (CWE) might be the best due to their hierarchy system and more general categories.
- CVE’s Vulnerability Abstraction has a decent breakdown more like my quick list above, but might be considered a bit lacking, or soon will be.
- The Web Application Security Consortium Web Security Glossary but it is web-centric.
That said, now I can get back to my original point! On September 29, Stefan Esser posted an advisory in which he said “While searching for applications that are vulnerable to a new class of vulnerabilities inside PHP applications we took a quick look…“. This lead me to remember an article last year titled Microsoft unveils details of software security process in which Window Snyder (former Microsoft security strategist) said “These are entire classes of vulnerabilities that I haven’t seen externally. When they found these, (the developers) went on a mission, found them in all parts of the system, and got rid of them.” referring to vulnerabilities that were proactively removed. The article goes on to say “Moreover, the company found and fixed two classes of vulnerabilities that have not been discovered elsewhere, she said.”
Anyone else curious about these? Less than a year, and three new classes of vulnerabilities? Come on Window, you left Microsoft, you can speak up now! Steffan, spill the beans, give us details!
Thanks for discussion and pointers: Steven Christey, Chris Wysopal, Sullo
BTW: it would be nice if your process of creating a candidate for inclusion in the CVE list makes sure that the security contact for the software is informed, so we don’t have to rely on some 3rd party to hear about this “DoS” for the software that we maintain. http://www.sendmail.org/security/
Yes, because the VDBs can maintain a list of vendors and think to mail each and every one regarding the 30 – 60 vulnerabilities disclosed each day. Yes, it is entirely our job to make sure you are informed that your code sucks ass. Had this been any vendor other than sendmail, you wouldn’t be reading this.
Hey Sendmail .. you hold the record, or are tied for, the WORST CODE EVER when it comes to security. Back in August of 1981 you were dealing with “multiple security issues”, you were a core part of the Morris Worm in 1988, and you have been a plague upon security administrators for 25 years. You do not have the right to talk to VDB admins like that sir.
There is a phrase about choosing who you sleep with because you may get fleas or some such. Claus, Sendmail as a program/group/whatever lost *all* rights to bitch about any vulnerability disclosure. In this case, that “3rd party” (you can hear him spitting as he typed that) is someone with OpenBSD, likely Theo de Raadt, who definitely knows security when it comes to coding. If that isn’t good enough, Sendmail (collectively) can shut their pie hole lest they choke on their own words:
SENDMAIL RELEASE NOTES
SECURITY: fix some buffer overruns; in at least one case this allows a local user to get root. This is not known to be exploitable from off-site. The workaround is to disable chfn(1) commands.
Let me quote the comment of another piece of working code as a response:
Hrm… and Eric Allman told me to my face that there were *no* buffer overflows in 8.7.5 — .mudge
This works on systems that have the chpass program runable by users. Tested on FreeBSD, though the vulnerability exists in all Sendmail8.7.5. Granted you need to be able to change your gecos field 😉
The problem is in buildfnam() which lives in util.c – it treats the static allocated array nbuf[MAXSIZE+1], from recipient.c, in an unbounded fashion.
[working exploit snipped]
While [John Carmack] said id Software is especially careful to lock down its game engines, companies that license and make changes to those engines often aren’t as focused, which could open the door to disaster.
While it hasn’t happened yet, Carmack thinks it’s just a matter of time before some clever hacker finds a way to insert a virus into a game engine.
“Security’s a twitchy thing,” he said. “If anything, the game industry has dodged a bullet because [when a virus does get inserted into a game engine] someone who’s playing a game at work will unknowingly let loose something catastrophic.”
From: Luigi Auriemma
Date: Fri, 2 Jun 2006 18:46:03 +0200
Subject: Client buffer-overflow in Quake 3 engine (1.32c / rev 795)
A Time to Patch III: Apple
Over the past several months, Security Fix published data showing how long it took Microsoft and Mozilla to issue updates for security flaws. Today, I’d like to present some data I compiled that looks at Apple’s performance on this front.
Here’s what I found: Over the past two years, after being notified about serious security flaws in its products, it took Apple about 91 days on average to issue patches to correct those vulnerabilities. I also found that almost without exception, open-source Linux vendors were months ahead of Apple in fixing the same flaws.
You can download a copy of the charts I put together either in HTML format or as a Microsoft Excel file. I spent a long time on this research, but that doesn’t mean it is free of typos and so forth. If you spot one, or a discrepancy in the data, please drop me line and I will update the data as necessary.