Sunday, July 13. 2008
A serious flaw in the way most DNS requests are made was announced last week. It is expected that the details of this issue will be known later this month when Dan Kaminsky presents at Black Hat. In the meantime, if you run a DNS server, be sure to get an update from your vendor.
On a side note about this issue, newer Linux kernels have a feature where the source port of UDP requests is randomized. That means that as long as the requesting application has random transaction IDs, it doesn't need additional logic to ensure random UDP source ports.
Package Manager Flaw?
A report came out last week titled: Attacks on Package Managers. The actual details of this are quite a bit less interesting that the reporter makes it sound. It's basically the same problem as using an out dated mirror.
Sunday, July 6. 2008
This week saw the release of a new Firefox. This means that I was horribly busy last week and most of this one. So this week, here are a few stories I found interesting, without my usual commentary to wreck any hope you had of enjoying the content
Ten tips for securing Linux desktops
Mozilla Security Metrics Project
Firefox users most likely to run latest version of the browser
I apologize for this and I hope the weekly entry will be back to normal next week.
Sunday, June 15. 2008
Verizon Data-Breach Study
Verizon Business released a very interesting report on data breaches in the enterprise.
Their findings are quite interesting, but two things especially stand out:
- Insider threat has decreased substantially.
- 90 percent of known vulnerabilities exploited had patches available for at least six months prior to the breach.
It seems that the single most important thing an administrator can do is to keep their system updated.
Sunday, June 1. 2008
The existence of the OSS-Security Community was announced last week. If you're interested in the unique challenges that Open Source software faces with respect to security, feel free to join the discussions within the group. As all communities go, the idea here is to grow a self sustaining community, not something that's just a few people doing all the work.
There were rumblings of a 0day Flash Player flaw in the wild. It turned out to be unpatched copies of Flash Player as noted on the
Adobe Product Security Blog. This is just another example of why it's very important to keep your system updated properly.
A quite serious Samba flaw was released last week
Initially this was thought to be quite minor, until it was noticed that it's possible for a Samba server to connect back to a client when doing certain printing actions. This means that this particular Samba client issue also affected the server. Quite tricky.
Sunday, May 18. 2008
By far the biggest event to happen last week was the OpenSSL mess. Most people have heard about this in some manner, but there is a lot of misinformation about all this, so I shall try to clear some things up.
What Really Happened
In September of 2006, Debian patched their version of OpenSSL in a manner that greatly reduced the entropy used in the OpenSSL random number generator (RNG). This is known as "seeding" the RNG. Computers are quite bad at doing "random" things. They are designed to be predictable, so when we need something like a random number, how is it done? There is an algorithm called the pseudo random number generator that generates a sequence of numbers that appears to be random. The randomness is determined by the initial seed. If you know the seed, you can easily determine the random numbers it will generate. What happened in this OpenSSL patch, is that most of the entropy used in the seed was removed, so basically only the process id (which is an integer between 0 and 32768) was used as the seed. The problem then becomes, that an attacker knows there are only 32768 possible seeds used in random number generation. For a fast computer, 32768 is a very small number.
What does it all mean
Right now, the program getting the most attention is SSH. SSH is affected in a couple quite different ways, all being quite serious.
The first is SSH keys. When you generate an SSH key, a random number is used to generate the key. If the random number used can be predicted, it's possible for a remote attacker to generate an exact copy of the SSH key. There are currently attempts underway to generate all possible SSH keys, which could then allow attackers to easily log into vulnerable accounts. Once a weak key is generated, it doesn't matter if it's used on a system with a properly functioning OpenSSL, the key is still weak and should be replaced. If you're not sure about your key, you should probably replace it.
SSH also uses something called a "host key" to identify a remote system to a user. The host key is used to ensure that the machine you are connecting is indeed the machine you think it is. If an attacker is able to generate a copy of the SSH host key, they can conduct a man in the middle type attack to steal sensitive data.
There is also the question about what happens if you've used a strong key on a weak host. This is an issue due to the way SSH works. Many of the steps involved in SSH authentication and data transmission requires good random numbers to work properly. That means that if you have a strong key, but use it on a system with a broken version of OpenSSL, it's possible that an attacker could capture the traffic and recover your private SSH key. If you only connected to (not from) a host with a weak OpenSSL, the data transfered could possibly be recovered, but your key should still be safe.
The Debian Wiki has a great deal of information about all this.
Sunday, April 20. 2008
There was a flurry of updates last week. It kept things quite busy and crazy. There wasn't much else going on (at least not much else I noticed).
The OpenOffice.org upstream made the unfortunate decision to release a new version (2.4), but not mention that it fixed a number of security flaws until almost a month later.
The news page makes reference of this.
Practices such as this can be quite dangerous, as people will read the release notes, think there are no security updates, then possibly not upgrade. In reality there isn't a huge threat here, it's more just bad practice. Silent security fixes are never a good idea, and have gotten numerous other organizations in hot water.
Sunday, March 30. 2008
I wish I had more to comment on this week. The Firefox release ate an extraordinary amount of my time, so there's not much content.
I ran across a story last week about researchers creating a secure web browser.
It seems there is work being done on a new secure web browser. The authors think that the current browsers suffer from fundamental design flaws that cannot be overcome. The notable thing is that from reading the article it's Open Source software being used. As the current offerings such as XULRunner and WebKit will allow various third parties to easily create niche browsers such as this. While this browser will likely never become a mainstream offering, it is nice that it can fill a hole in the current offerings.
Firefox 184.108.40.206 was released this week. There's not much to say beyond, make sure you're running it.
Sunday, March 23. 2008
Wells Fargo Online Safe-Deposit Box
It's no secret that even with a brick and mortar bank, you have to have a certain level of trust with a save-deposit box. But apart from a dishonest employee, the evildoers will have a rough time getting at your things. You would expect the bank to have at least, door locks, security cameras, motion detectors, and a big thick scary vault.
With an online storage system you really don't have all that many lines of defense. Let's presume the tech guys aren't thieves, and there are no flaws that could be used to gain access to your account. That means that the only real way in is to steal your "key". In the physical world, that might be as difficult as targeting you, knocking you down in the street, rummaging through your pockets, and finding the bank key. Then all you have to do is trick the bank into letting you actually use the stolen key, and taking whatever unusually important things I have stowed away in my box. In the tech world, I suspect stealing keys would go something like this:
Send out twelve billion phishing emails. Get some login credentials, steal their files.
The article mentions RSA tokens, which would help considerably, but they seem to suggest they are optional. I would be quite hesitant to put much faith in such a system if it doesn't offer multi factor authentication. Like most things though, I suspect this is just a case of making people feel all warm and fuzzy, since they don't really understand what's going on anyhow.
CERT-FI archive file fuzzing
CERT-FI published a giant archive of fuzzed files last week.
There are a couple of things that will need to be fixed in Fedora and RHEL, they are currently being worked on, but this really brings up a much bigger question. How is this a security advisory? They gave out an archive of millions of fuzzed files, the vast majority of which don't even trigger bugs in the software in question.
I think fuzzing is extremely powerful, and is very useful for finding bugs and security issues. Until now, fuzzing has really focused on the tools that mangle the data, to produce data with errors and flaws that will trigger bugs. These tools are a dime a dozen at this point, so what CERT-FI did wasn't all that useful. It would have been far more useful had CERT-FI distributed their suite for generating the fuzzed files, or released a test runner. Currently, the hard part when fuzzing is actually running the tests. When something fails, it's helpful to know where and why it happened, and by the very nature of fuzzing, there will be many failures caused by the same bug.
This also begs the question, what's coming next? Given what I've seen of fuzzing, I think it's beginning to reach the end of its extreme usefulness. Once fuzzing stops returning quick and easy results, I imagine most researchers will move on to something better for finding their flaws. It's in the best interest of security researchers to quickly and easily find security issues.
This reminds me of strcpy usage a few years back. There were an incredible number of security bugs found back when nobody cared about how they handled strings. Most developers are now quite aware of this and the strcpy buffer overflows are rather uncommon. Modern compilers will now even complain about crummy string use. Fuzzing is really just finding bugs where developers don't verify user input. This is getting better, and eventually ensuring that user input is sane will likely just be common knowledge. It shall be interesting to see what clever researchers come up with next, but until then, keep up the fuzzing.
Sunday, March 16. 2008
Last week was quite slow as far as security goes. This isn't always a bad thing (unless you have a weekly column you write).
Browser makers focus on beating malware
This is a rather interesting story about some of the new features we can expect to see in the next generation of browsers:
As bad as security is in some areas, it's nice to see the browser market taking proactive steps about the problems. Most people just take their browser for granted, but it's probably one of the most complicated pieces of software they run, and its primary purpose is to process untrusted third party content in a safe manner. This is not an easy thing to do right. For the most part they do a great job of this.
Sunday, March 9. 2008
Improve security with polyinstantiation
There is a really good article about using directory polyinstantiation in PAM:
I hope to see this used by default in an upcoming Fedora release. All the bits are there, someone just needs to put them together. The basics are that each user gets their own personal /tmp for example. This then (mostly) eliminates things like insecure temp file usage flaws.
Evolution or Intelligent Design?
A quite serious Evolution critical issue was released last week:
This issue would allow an attacker to inject arbitrary code into your evolution process if you view the malformed message. There's not really a good way to protect against this, as the very nature of email is to view the messages you receive. Many people got very little sleep in order to release a timely update for this one.
A big thanks should go out to Secunia for giving everyone a heads up about this. If you're running Evolution and you've not updated yet, you should do so.
Sunday, February 24. 2008
A rather scary looking bug was noticed in CUPS last week:
CUPS "process_browse_data()" Double Free Vulnerability
This is always one of the things that makes security and Open Source quite the challenge, yet also something positive. This bug was reported to the CUPS project in January, but nobody noticed until last week that it was even there. In a closed source project, a bug such as this would probably go unnoticed, and never be called a security issue. The "many eyes" aspect of Open Source is what got this noticed, and thanks to Secunia, the various interested vendors shipping a vulnerable version of CUPS were able to apply the fix to keep their users secure.
Disk Encryption Isn't So Safe
New Research Result: Cold Boot Attacks on Disk Encryption
This research paper is quite brilliant, while also being amazingly simply when you really think about it. It's never been a secret that RAM can hold its contents for an extended period of time. It's assumed that it should be possible to inspect RAM under an electron microscope and reveal the previous contents long after a machine has been powered off. The scary thing about this paper is that simply quickly rebooting a machine should make it quite possible to extract previous RAM contents.
While I don't think it's worth building a bomb shelter in your backyard over this, any paranoid tech traveler should be aware of this paper.
I received a question about inspecting computer memory to discover its previous contents. As I recall hearing about this during a lecture in my undergraduate days, I decided to see what Google has to say. Here are the search terms that should return some interesting results:
data remanence volatile semiconductor memory
Sunday, February 17. 2008
Kernel Local Root
The most exciting thing to happen last week was probably all the attention CVE-2008-0600 got. This flaw could allow a local user to gain root privileges, and things such as SELinux wouldn't stop it. The significant part isn't the local root in itself, but rather that there were working exploits available in the wild. There are always kernel privilege escalation flaws, but there are not always easy working exploits.
This was of course fixed quite promptly in both Red Hat Enterprise Linux and Fedora.
Sunday, February 10. 2008
A new version of Firefox was released this week, and that means a great deal of my time was consumed by the various things that have to happen regarding such an event. This also means the content is quite slim.
This week Mozilla released a new version of Firefox:
As usual it fixes some rather dangerous flaws.
How Does SELinux Work?
I ran across this article this week. it's not too shabby explaining how SELinux works. It's a decent read for anyone interested in this sort of thing.
Sunday, January 27. 2008
Enterprise-grade Linux: Five network security FOSS apps
iTWire has a story detailing five open source security applications:
As more security applications are gobbled up by large firms, open source projects gain a unique advantage. Anytime an organization needs to make money, they are willing to draw a gray line with respect to their ethics. As most open source projects don't rely on corporate funding, they can be more strict with respect to what they call malware. It is quite likely that as the volume of malware increases, this advantage will become more clear.
Growing virus production taxes security firms
The Register points out the current problem with growing malware trends:
The rate at which malware is growing is quite alarming. If this trend continues it will become impossible for anti virus firms to keep ahead of the wave. The current attitude toward malware is to take a very reactive approach. Most groups don't focus on stopping the cause of problems, but rather treating the symptoms. While there is certainly a great deal of money to be made in treating symptoms, the well is going to dry up eventually.
Sunday, January 20. 2008
New versions of X.org were released this week.
The tricky thing with X.org is that it has to run as root, so it gives a local attacker the potential to compromise the machine.
More Vulnerability Reporting
A report was made public last week that once again compares the number of flaws fixed in various things. I think Mark Cox and Window Snyder summed things up pretty well regarding those reports:
At this point any intelligent reader should notice that these reports need to be taken with a grain of salt, and the real story isn't what's reported, but what one can learn from the data.
Embedded library madness
Right now there has been a bit of news from a company named Palamida. They like to point out all the things that contain embedded copies of various open source projects.
Before 2002 this was a fairly common occurrence within a number of open source projects, until there were a number of zlib flaws. This made most project rethink keeping their own local copies of the source and using the system copy instead. This ties in nicely with the above mentioned vulnerability report. More vulnerabilities doesn't always mean less secure.
So a coworker pointed me at his blog today, which discusses a few really nice tools for those of us in the security world:
These tools should help with the analysis of various bits of software. Figuring out what a piece of malware is doing can always be challenging. Knowing what signals are being trapped along with what files are open can be most useful.
Syndicate This Blog