Posts in Secure IT Practices
Page Content
Quicktime flaw on Macs brings out the crazies
[tags]Windows,MacOS, security flaws, patches, press coverage[/tags]
There's been a lot of froth in the press about a vulnerability discovered in a “Hack the Mac” contest conducted recently. (Example stories here and here.) I'm not really sure where this mini-hysteria is coming from -- there isn't really anything shocking here.
First of all, people shouldn't be surprised that there are security flaws in Apple products. After all, those are complex software artifacts, and the more code and functionality present, the more likely it is the case that there will be flaws present -- including serious flaws leading to security problems. Unless special care is taken in design and construction (not evident in any widely-used system) vulnerabilities are likely to be present.
Given that, the discovery of one serious flaw doesn't necessarily mean there are hundreds more lurking beneath the surface and that MacOS X is as bad (or worse) than some other systems. Those bloggers and journalists who have some vulture genomes seem particularly prone to making sweeping announcements after each Apple-based flaw (and each Linux bug) is disclosed or a story about vulnerabilities is published. Yes, there are some problems, and there are undoubtedly more yet to be found. That doesn't mean that those systems are inherently dangerous or even as buggy and difficult to protect as, for example, Windows XP. Drawing such conclusions based on one or two data points is not appropriate; these same people should likewise conclude that eating at restaurants anywhere in the US is dangerous because someone got food poisoning at a roadside stand in Mexico last year!
To date, there appear to be fewer flaws in Apple products than we have seen in some other software. Apple MacOS X is built on a sturdy base (BSD Unix) and doesn't have a huge number of backwards compatibility features, which is often a source of flaws in other vendors' products. Apple engineers, too, seem to be a little more careful and savvy about software quality issues than other vendors, as least as evidenced by the relative number of crashes and “blue screen” events in their products. The result is that MacOS X is pretty good right out of the box.
Of course, this particular flaw is not with MacOS X, but with Java code that is part of the Quicktime package for WWW browsers. The good news is that it is not really a MacOS problem; the bad news is that it is a serious bug that got widely distributed; and the worse news is that it potentially affects other browsers and operating systems.
I have been troubled by the fact that we (CERIAS, and before that COAST) have been rebuffed on every attempt over the last dozen years to make any contact with security personnel inside Apple. I haven't seen evidence that they are really focused on information security in the way that other major companies such as Sun, HP and Microsoft are, although the steady patching of flaws that have not yet been widely reported outside the company does seem to indicate some expertise and activity somewhere inside Apple. Problems such as this Quicktime flaw don't give warm fuzzy feelings about that, however.
Apple users should not be complacent. There are flaws yet to be discovered, and users are often the weakest link. Malware, including viruses, can get into MacOS X and cause problems, although they are unlikely to ever be of the number and magnitude as bedevil Windows boxes (one recent article noted that vendors are getting around 125 new malware signatures a day -- the majority are undoubtedly for Windows platforms). And, of course, Mac machines (and Linux and....) also host browsers and other software that execute scripts and enable attacks. Those who use MS Word have yet more concerns.
The bottom line. No system is immune to attacks. All users should be cautious and informed. Apple systems still appear to be safer than their counterparts running Windows XP (the jury is out on Vista so far), and are definitely easier to maintain and use than similarly secured systems running Linux. You should continue to use the system that is most appropriate for your needs and abilities, and that includes your abilities to understand and configure security features to meet your security needs. For now, my personal systems continue to be a MacBook Pro (with XP and Vista running under Parallels) and a Sun Solaris machine. Your own milage should -- and probably will -- vary.
I told you so
[tags]Windows, Office, malware, vulnerabilities[/tags]
This appeared in USA Today yesterday: Cyberspies exploit Microsoft Office. This is yet more support for my earlier post.
So, are you ready to join the movement -- stop sending Word documents in email?
Update 4/28: And here is yet another story of how Word files are being used against victims.
[posted with ecto]
The PHP App Insecurity Top 20
I’ve spent some of my down time in the past couple weeks working with the NIST NVD data to get stats on PHP application vulnerabilities. What follows is a breakdown of the 20 PHP-based applications that had the highest aggregate vulnerability scores (NIST assigns a score from 1-10 for the severity of each entry), and the highest total number of vulnerabilities, over the past 12 months. Of the two, I feel that the aggregate score is a better indicator of security issues.
A few caveats:
- The data here covers the period between April 1 2006 and April 1 2007.
- This obviously only includes reported vulnerabilities. There are surely a lot more applications that are very insecure, but for one reason or another haven’t had as many reports.
- I chose 20 as the cutoff mainly for the sake of making the data a little easier to swallow (and chart nicely). There are about 1,800 distinct apps in the NIST NVD that are (as far as I could determine) PHP-based.
Without further ado, here are the tepid Excel charts:
A couple notes:
- There are 25 entries in the top “20” by vulnerability count, due to matching vulnerability counts.
- I’d never even heard of MyBulletinBoard, the top entry in both lists. It hasn’t had any vulnerabilities in the NVD since September of 2006, which says something about how numerous and severe the entries between April and September 2006 were. This appears to be the same product as “MyBB,” so perhaps the situation has improved, as MyBB only has one NVD entry in the entire period (CVE-2007-0544).
- Wordpress has had a bad start to 2007, with numerous vulnerabilities that significantly increased its ranking. March 2007 was particularly bad, with 7 new vulnerabilities reported.
- Bulletin board/forum software is by far the most common type of application in the top 20. A couple forum apps that have very low numbers of vulnerability reports: Vanilla and FUDForum.
I do intend to keep this data up-to-date if people find it interesting, so let me know if you’d like me to do so, or if you’d like to see other types of analysis.
[tags]php, security, application security, vulnerabilities, nist, nvd, statistics[/tags]Do Open Source Devs Get Web App Security? Does Anybody?
A colleague of mine who is dealing with Plone, a CMS system built atop Zope, pointed me to a rather disturbing document in the Plone Documentation system, one that I feel is indicative of a much larger problem in the web app dev community.
The first describes a hole (subsequently patched) in Plone that allowed users to upload arbitrary JavaScript. Apparently no input or output filtering was being done. Certainly anyone familiar with XSS attacks can see the potential for stealing cookie data, but the article seems to imply this is simply a spam issue:
Is this a security hole? No. This is somebody logging in to your site (if you allow them to create their own users) and adding content that can redirect people to a different web site. Your server, site and content security is not compromised in any way. It's just a slightly more sophisticated version of comment spam. If you open up your site to untrusted users, there will always be a certain risk that people add content that is not approved. It's annoying, but it's not a security hole.
Well, yes, actually, it is a security hole. If one can place JavaScript on your site that redirects the user to another page, they can certainly place JavaScript on your site that grabs a user's cookie data and redirects that to another site. Whether or not they'll get something useful from the data varies from app to app, of course. What's worrisome is that it appears as if one of Plone's founders (the byline on this document is for Alexander Limi, whose user page describes him as “one of Plone's original founders.”) doesn't seem to think this is a security issue. After getting feedback from Alexander Limi, it seems clear that he does understand the user-level security implications of the vulnerability, but was trying to make the distinction that there was no security risk to the Plone site itself. Still, the language of the document is (unintentionally) misleading, and it's very reminiscent of the kinds of misunderstandings and excuses I see all the time in open-source web app development.
The point here is (believe it or not) not to pick on Plone. This is a problem prevalent in most open source development (and in closed source dev, from my experience). People who simply shouldn't be doing coding are doing the coding -- and the implementation and maintenance.
Let's be blunt: A web developer is not qualified to do the job if he or she does not have a good understanding of web application security concepts and techniques. Leaders of development teams must stop allowing developers who are weak on security techniques to contribute to their products, and managers need to stop hiring candidates who do not demonstrate a solid secure programming background. If they continue to do so, they demonstrate a lack of concern for the safety of their customers.
Educational initiatives must be stepped up to address this, both on the traditional academic level and in continuing education/training programs. Students in web development curriculums at the undergrad level need to be taught the importance of security and effective secure programming techniques. Developers in the workforce today need to have access to materials and programs that will do the same. And the managerial level needs to be brought up to speed on what to look for in the developers they hire, so that under-qualifed and unqualified developers are no longer the norm on most web dev teams.




