Sunday, July 29. 2007Security Week in Review (2007-07-22)
Dangerous Firefox Flaw
This week there has been a fair amount of talk regarding a new Firefox flaw that can allow a web site to execute arbitrary commands as the user running Firefox. Window Snyder has more information about this here. It turns out that the issue here is how Firefox launches helper applications. Specifically, how Firefox launches helper applications in Windows. In the Linux version of Firefox, when a helper is launched Firefox will do a forkexec of the binary. This basically means that the way the arguments are passed to the helper are well understood. In the windows world, this is not well understood and has led to confusion and a rather dangerous security flaw. What's happening is basically that the URL is handed to a special Windows function that builds the argument list, then launches the URL handler. This is a perfect example of why relying on closed source solutions are a problem. Nobody actually understood this problem for several days, and even now how can it be proven the Firefox fix will be correct? Without the ability to view the source, or adhere to standards, application writers are at a serious disadvantage. It is very likely that there are countless other applications that suffer from this same bug, but since they lack the attention Firefox has, the bug will never be fixed. IE even suffers from this flaw, which Microsoft claims isn't really a security bug. It's easy to say that open source has significant security advantages, but situations like this make it hard to believe any argument in favor of a closed system. Sunday, July 22. 2007Security Week in Review (2007-07-15)
Computer Viruses are 25 Years old
I ran across this story this week. http://www.sciam.com/article.cfm?chanId=sa003&articleId=C0C3AC3C-E7F2-99DF-39AA1A7175A11775 The computing world is still suffering from computer viruses. They're a serious problem that waste a great deal of time and money. Given past trends, it's very likely that computer viruses will see their 50th birthday. Serious Security Issues in Samsung Linux Drivers This story is absolutely amazing http://it.slashdot.org/article.pl?sid=07/07/18/0319203 It seems that by installing certain Samsung Linux drivers modify numerous applications on the local system, setting a number of them setuid-root. It's easy to claim open source produces higher quality software, this is a fine example of this. If the source is being scrutinized by the community at large, someone is likely to send a patch which can fix a plain stupid bug such as this. It's also quite likely that a developer will be more willing to "do it right" if the source is going to be available for the whole world to see. Firefox 2.0.0.5 Released A new version of the Mozilla products (Firefox, Seamonkey, Thunderbird) were released this week. http://www.mozilla.org/projects/security/known-vulnerabilities.html#firefox2.0.0.5 It's rather important you ensure you've installed this update as the browser is certainly the most abused application these days. If you run Fedora, this update has been available via yum for several days. Wednesday, July 18. 2007The Act of Purchasing Security Flaws
Today I found this essay on Slashdot:
Bill Gates Should Buy Your Buffer Overruns I found this essay rather short sighted, the author is obviously biased toward being paid for vulnerabilities. This may sound like a grand capitalism meets software idea to some, but I have no doubt it's a bad idea. I know most other who actually do the work of keeping users secure agree with me. I'm obviously biased as well, so I feel compelled to comment on this concept. A program that pays researchers for flaws is easily a huge liability for both the researcher and the company purchasing the flaw. There are a number of possible scenarios that can emerge causing potential problems for all involved parties. If the research leaks, should the researcher get paid? What if someone else leaks the informatoin? If a researcher is willing to be paid for the exploit, why not just pay them to keep quiet? It's no doubt a tempting idea. What happens if it's stolen research? It's no secret that many security people talk to each other, and help each other out from time to time. What if a researcher wants to be paid via a brown paper bag dropped in a garbage can? A large multinational corporate has a lot to lose. I have no doubt any good legal department would be kept up late into the night over such a program as this. The issue of extortion is also of grave concern here. What would stop a researcher from asking for 10 times what a company is willing to pay? What happens when you're backed into a corner of paying for a flaw, or knowing they researcher will sell it on the black market. Is that neglegence? Perhaps we should think of this in a different way. I'm going to make up a story. So Bob discovers a security flaw in Bigco's new Wizbang Interweb Widgetifyer version 17,000. Bigco usually pays researchers $1000 for finding security flaws that could be leveraged to spread a worm. Bob decides that his flaw is easily worth $10,000, and tells Bigco that. Bigco tells Bob to bugger off, they won't pay his extortion fee. Bob decides he's just going to release the exploit on a public mailing list and hope someone writes a worm. Bigco deserves this since they won't take him seriously. So the exploit is released, a worm is written and starts spreading across the world. Luckily since only 99% of the computers on the Interweb run Wizbang Internet Widgetifyer version 17,000, the Interweb manages to stay up. At this point Bigco starts telling everyone to feel bad for it becuase Bob tried to extort money from them, then he wrote a worm to teach them a lesson. He's obviously a terrible horrible person who probably has three heads and eats raw meat. People start telling Bob what a horrible person he is, and they threaten to kick his puppy. The moral of this story is basically two fold here. A computer monoculture is an issue. If most of the computers run the same program, it creates a more lucrative market for certain exploits. The second moral is that if you are willing to give someone one, they think they deserve two. I'm very skeptical that a researcher could earn a living selling flaws for a few thousand dollars a pop. It takes way to long and is far too much work to actually develop a working, non lame, exploit. I suspect it makes more sense for a researcher to gain as much attention as possible by being credited in public. This would in turn lead to a full time gig somewhere doing something security related. Tuesday, July 17. 2007Keeping things secure
So I've been thinking about how various things can be kept secure these days. I've been spending a fair amount of time ensuring that my son who is learning to walk isn't going to kill himself one of the seven million ways that are possible in a normal home. I of course keep relating this to computer security. I'm just a bit weird like that.
The current model of security I'm installing in my house isn't meant to keep an evildoer out, it's meant to keep a resident safe from unsafe things. This isn't much different from most computer users. They don't know what they're doing, and giving them full unbridled access to their computer is probably a bad idea. I'm not advocating DRM here, think the horrible mess that the Windows world faces with most users running as admin, and the damage a virus can do. This is where the concept of not running as root seems perfectly obvious. So now in my house, if I need root access, I can open one of the drawers or gates, while a curious little boy cannot. This can however cause problems for some users. Perhaps there is a user (the dog) who wants to do something as root but doesn't know the password (opposable thumbs). The poor dog is pretty much screwed until I open whatever gate he is stuck behind. Those of you who own dogs also happen to know the saying "a dog is always on the wrong side of a closed door" is very true. This particular user has no idea what he wants, but think he needs root. I have no realy point to this, just a bizarre observation of the world around me. Sunday, July 15. 2007Security Week in Review (2007-07-08)
Flash Player Security Update
http://www.adobe.com/support/security/bulletins/apsb07-12.html Adobe released a new version of flash player last week. The update in itself isn't terribly significant, but this brings up a great opportunity to stress the importance of not running Flash Player as a standalone plugin. Firefox currently has the ability to magically install Flash Player if you visit a site that requires it, and you don't have it installed. The problem with this installation method is that you will never get security updates for your local copy. Fedora users should install flash from mplug.org here: http://macromedia.mplug.org/ This is a great service Warren provides. As long as you rely on this yum repository for Flash Player, you should receive the necessary updates to keep your browser secure. Updated Unknown to me at the time of writing, the flash packages should not be retrieved directly from Adobe. There is a statement on the mplug.org site: This site used to host RPM and yum/apt repositories of Adobe Flash Player. Security and Accountability http://blog.mozilla.com/security/2007/07/10/security-issue-in-url-protocol-handling-on-windows/ Last week a security flaw was found in the way Internet Explorer passes a URL to Firefox. This done via a special protocol handler that Firefox registers when installed on a windows system. Microsoft claims this isn't their problem, Mozilla claims it is. Luckily this flaw is going to be fixed in Firefox. It's admirable that the Firefox developers are willing to do what's best for their users. The moral of this story is that there are significant advantages to the current Linux distribution model. If a similar flaw was found in Fedora or Red Hat Enterprise Linux, there is nobody to bicker with. It's not uncommon for vendors to spend more time pointing fingers at each other when something goes wrong. There can certainly be an advantage to getting all your bits from one place. Sunday, July 8. 2007Security Week in Review (2007-07-01)
Why an ATM PIN Has Four Digits
Bruce Schneier has an interesting blog entry which explains why our ATM PIN is four digits. A four digit password is laughable, but in the same respect, so is writing your password down and sticking it to your monitor. A big reason a four digit PIN works for an ATM is that you also need the ATM card in order to use the PIN. That's known as two factor authentication, what you know (PIN) and what you have (card). Any group that wishes to keep their users secure will rely on a multi factor authentication system. It's a lot harder to steal my ATM card and my PIN than it is to find just one of them. From a user perspective it makes more sense to let them choose a crappy password they can remember, then secure their crappy password with something like smart card or token. Vulnerability for sale Another vulnerability auction site has arisen. This isn't the first site to attempt this and surely won't be the last. Most of these sites are really just marketing scams that attract a great deal of attention to the group conducting the auction. It's very possible that these flaws are real, but it's far more likely they are extremely lame flaws, or are just plain fakes. Even if these flaws prove to be real, one of the significant advantages to open source software is the speed that flaws can be fixed. There are few companies that can claim to have a large group of well qualified people able to help develop a fix for a flaw. Rather than fret over a site such as this, it makes far more sense to just keep doing the things that make Open Source great, and deal with bumps as they appear. Sunday, July 1. 2007Security Week in Review (2007-06-24)
Red Hat Linux Gets Top Government Security Rating
The news of Red Hat Enterprise Linux 4 attaining EAL4 + LSPP is important to the entire Linux community. Red Hat Enterprise Linux 4 now holds the highest possible government security rating that can be acquired by an off the shell operating system. A great deal of work has gone into this certification, but it speaks volumes about the maturity of Linux. It is unlikely that any other operating system in history has progressed so quickly in so many directions. No doubt this is a great example of how impressive the open source development model can be. This particular certification is due to the progress made with SELinux. SELinux is still a relatively young addition to the Linux kernel. No doubt great things will be accomplished with SELinux in the future. Third-Party Severity Ratings The above story compares how Red Hat rated the severity of a number of security flaws compared to how The National Vulnerability Database (NVD) rated the same flaws. The Red Hat Enterprise Linux ratings are comparable to how the same flaws are rated for Fedora. The one sentence summary is that the way Red Hat rates flaws and the way NVD rates flaws is different. The analysis in the article does a nice job of explaining why this likely is. Fedora Security Response Team The Fedora Security Response Team is still moving along. Things aren't moving terribly fast, but they are moving. The team is still primarily slogging through the list of old CVE ids to ensure that we've not missed anything in Fedora 7. I hope to use this article to keep the community in general up to date on the progress of security issues in Fedora.
(Page 1 of 1, totaling 7 entries)
|
CalendarQuicksearchCategoriesSyndicate This BlogBlog Administration |
