Josh's Blog - Security

Security Week in Review (2008-07-28)

nospam@example.com (Josh Bressers) — Thu, 31 Jul 2008 22:00:00 +0000

Last week wasn't very exciting as far as security issues go. I have nothing of interest to note. Next week should be quite busy though.

Black Hat and DEFCON are going on in Las Vegas. Things are expected to be very busy.

Security Week in Review (2008-07-13)

nospam@example.com (Josh Bressers) — Sun, 20 Jul 2008 22:00:00 +0000

Security Circus
By far the most entertaining story from last week was Linus giving a few choice quotes.

He does get some things right, but there's still the very real fact that security flaws let people do things they shouldn't be able to do. This adds a certain amount of danger and does require more attention than some other flaws. A nice comparison is automotive recalls. If there are two problems, one is a broken cup holder, the second makes the car explode, which do you think they'll do a recall for?

principle of least privilege
Steve Grubb has a nice interview up on SearchEnterpriseLinux.com.

It offers some hints into some of the intresting things that have happened and can be expected in the SELinux space.

Full Disclosure in the Linux Kernel?

nospam@example.com (Josh Bressers) — Thu, 17 Jul 2008 11:36:00 +0000

There has been a lot of squabbling about disclosing security issues, specifically in the Linux Kernel as of late.

This is probably getting a lot more attention than it should. There are two ways this can be dealt with.

1) Insist the bikeshed be painted your favorite color. Complain to no end that it's not fair that you have to look through the source code to find your own fixed security issues. This is open source, everything is full disclosure. The guys who take care of the Linux Kernel do a top notch job, and they cover the security bits quite well. I've yet to see anyone who isn't an annoying troll say something negative about the job they do.

2) Deal with it. Dig around in the mud, find the problems, talk about them, fix them, write exploits for them. This is what myself and a team of very bright people do for Red Hat. It's not always pleasant (usually not), but we deal with it. Sometimes things are embargoed, sometimes they're not. We don't complain about it, we do our jobs.

The goal here is to keep the end users safe. Not to become famous, not to get a t-shirt made with our catchy slogan on it. Safe users. That's it.

Security Week in Review (2008-07-06)

nospam@example.com (Josh Bressers) — Sun, 13 Jul 2008 22:00:00 +0000

DNS flaw
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.

Security Week in Review (2008-06-29)

nospam@example.com (Josh Bressers) — Sun, 06 Jul 2008 22:00:00 +0000

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.

Security Week in Review (2008-06-08)

nospam@example.com (Josh Bressers) — Sun, 15 Jun 2008 22:00:00 +0000

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.

Security Week in Review (2008-05-25)

nospam@example.com (Josh Bressers) — Sun, 01 Jun 2008 22:00:00 +0000

OSS-Security
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.

Flash Player
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.

Samba
A quite serious Samba flaw was released last week
http://us1.samba.org/samba/security/CVE-2008-1105.html

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.

Announcing oss-security

nospam@example.com (Josh Bressers) — Tue, 27 May 2008 09:54:00 +0000

Today I'm happy to announce the Open Source Software Security community. This project is an ongoing effort to manage security information in Open Source software by building on the collaborative foundation of the open source model. You can find the official announcement on the Red Hat News page, and the mailed announcement.

More information can be found on the group's wiki page here:
http://oss-security.openwall.org

Security Week in Review (2008-05-11)

nospam@example.com (Josh Bressers) — Sun, 18 May 2008 23:00:00 +0000

OpenSSL
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.

OpenSSL random number generator flaw (CVE-2008-0166)

nospam@example.com (Josh Bressers) — Tue, 13 May 2008 13:25:08 +0000

A flaw was discovered in a third-party vendor patch to the OpenSSL library which affected random number generator seeding (CVE-2008-0166). This patch has never been used by Red Hat, and this issue does not affect any Fedora, Red Hat, or upstream supplied OpenSSL packages.

Any cryptographic keys or encrypted data generated on a system using a distribution which was affected may be predictable and should be replaced. Affected vendors will be publishing advisories and advice on how to do this.

Security Week in Review (2008-04-13)

nospam@example.com (Josh Bressers) — Sun, 20 Apr 2008 18:00:00 +0000

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).

Firefox
There was another Firefox update on the heels of the last one. This was to fix a quite serious flaw discovered in the way Javascript is handled. Firedrill updates are never much fun, but as usual all the pieces eventually fit together and updates made it out. Be sure you're running the latest browser, as it's easily the easiest entry point into a system.

OpenOffice.org
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.

Security Week in Review (2008-03-23)

nospam@example.com (Josh Bressers) — Sun, 30 Mar 2008 22:00:00 +0000

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.

Secure Browser?
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 2.0.0.13
Firefox 2.0.0.13 was released this week. There's not much to say beyond, make sure you're running it.

Security Week in Review (2008-03-16)

nospam@example.com (Josh Bressers) — Sun, 23 Mar 2008 22:00:00 +0000

Wells Fargo Online Safe-Deposit Box
http://www.sci-tech-today.com/news/Wells-Offers-Online-Safe-Deposit-Box/story.xhtml?story_id=11200CI7MS74

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.
https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html

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.

Security Week in Review (2008-03-09)

nospam@example.com (Josh Bressers) — Sun, 16 Mar 2008 22:00:00 +0000

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:
http://www.securityfocus.com/news/11508

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.

Security Week in Review (2008-03-02)

nospam@example.com (Josh Bressers) — Sun, 09 Mar 2008 22:00:00 +0000

Improve security with polyinstantiation
There is a really good article about using directory polyinstantiation in PAM:
http://www.ibm.com/developerworks/linux/library/l-polyinstantiation/?ca=dgr-lnxw02LinuxPAMSecurity&S_TACT=105AGX59&S_CMP

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:
http://secunia.com/advisories/29057/

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.