Pascal Meunier writes

The entry for CVE-2006-4339 reached 16941 bytes, with 352 references. This is an OpenSSL issue, and highlights how much we are dependent on it.

Vulnerabilities in any security suite aren’t something you ever want to hear about, particularly something as ubiquitous as OpenSSL. Whenever you use an application that has SSL capabilities, there’s a good chance you’re relying on OpenSSL for security, especially if the software doesn’t come from a company that has its own proprietary security suite (such as Microsoft or Mozilla). VMWare, Opera, various products from Sun, any Apache instance using mod_ssl…there’s a lot out there that needs to be patched right now. You may want to do a quick search of your systems for ssleay32.dll/so and libeay.dll/so to see if you have anything that needs updating.

This year’s PWN 2 OWN contest allowed security researchers to choose between machines running 3 different operating system flavors: Linux, OS X, and Vista.

Charlie Miller (of iPhone fame) was able to exploit a vulnerability in the Safari web browser that allowed him to take over the MacBook Air running OS X in about 2 minutes, winning him $10k.

From Engadget :

Apparently Mr. Miller visited a website which contained his exploit code (presumably via a crossover cable connected to a nearby MacBook), which then “allowed him to seize control of the computer, as about 20 onlookers [read: unashamed nerds] cheered him on.” Of note, contestants could only use software that came pre-loaded on the OS, so obviously it was Safari that fell victim here.

It just goes to show— vulnerabilities can exist anywhere and new ones are always being discovered. Just because you run a certain operating system or you use a certain type of software doesn’t mean you should let your guard down.

Washington state is scheduled to pass House Bill 1031 (pdf) , making it a class C felony to skim personal data from RFID cards and documents.

A person that intentionally scans another person’s identification device remotely, without that person’s prior knowledge and prior consent, for the purpose of fraud, identity theft, or for any other illegal purpose, shall be guilty of a class C felony.

This is good since Washington is one of the four states in cooperative agreements with the Department of Homeland Security to use the RFID technology in their enhanced drivers licenses as the national PASS Card which the federal government is making available to US citizens who frequently cross borders into Canada and Mexico.

I like to see the fact that at least criminals can now be prosecuted for committing a crime. But it still annoys me that the entire program is still only run around Gen-2 based RFID technology specifications. This leaves quite a few security holes still. Though for this specific program the State Department claims there is no threat due to the fact that they only store a unique ID number on the card, and no personal information. But what’s to keep these IDs from being compromised.

As our lives become “easier” and more “convenient”, we tend to overlook what we are giving up in trade off. But at least someone in the government is paying some kind of attention to technology, and making an attempt to help protect us.

Throughout our lives we are taught, beginning from when we are children, to never say never. A good philosophy since nothing in the universe is absolute, just a matter of probabilities. The reverse – never say always – is equally as true, since again, nothing is absolute.

As security professionals, we’re told to do completely the opposite. We’re encouraged to say ‘never’ and ‘always’ with the knowledge that sometimes those 2 words just don’t apply.

The logic behind such wording is sound – you don’t want the people you’re protecting to get the wrong idea about a certain setting, firewall configuration, or password policy. Let your customers deal in absolutes without losing sight of everything in between.

That’s what security professionals bring to the table – a specialized
mindset that can see all of the shades of gray. Everything in between ‘never’ and ‘always’ is where security professionals live. They know when ‘never’ is really never, and always is 99.9% always.

Most people, when it comes to security, see the black and white making it seem like once you get the dos and don’ts, anyone can take over. That’s slowly changing and companies and governments are learning to appreciate the shades of gray. Perhaps it’s because they’re increasingly employing the expertise of security professionals or they see when ‘never’ and ‘always’ fail.

That’s the art of security, to paint black and white using only red, yellow, blue, and purple. If you’re in the security field, the more experience you gain, the more gray you see; if you’re on the other end you get pretty good at seeing black and white.

Security is a series of trade-offs based on ever changing probabilities. The better versed you are in the probabilities, possibilities, and perceptions the better you’ll be able to help a client with a given security problem.

Security is about being flexible, not rigid — how you perceive that line says alot about how you view the world of never, always, and everything in between. Let us know in the comments.

We’ve said it before and we’ll say it again now that a security upgrade made it possible for strangers to view private photos on Facebook. Don’t put things online that you don’t want people to know.

The Associated Press verified the loophole Monday after receiving a tip from a Byron Ng, a Vancouver, Canada computer technician.

Facebook had just added more privacy controls for users to decide who is able to view certain portions of their profiles.

But the added protections were not enough to prevent Ng from pulling up the most recent pictures posted by Facebook members and their friends, even if the privacy settings were set to restrict the audience to a select few.

Ng was able to check out some private photos of Paris Hilton at the Emmys, and an AP reporter viewed a photo album posted by Facebook’s founder Mark Zuckerberg.

So, here’s a short quiz to see if you’ve understood the material. You should (A. always, B. never) put things online that you don’t want people to know.

However, it’s probably not what you think… They’re not using PKI, or SecurID, or those cruddy images we’ve mentioned before. No, this time they are using Entrust IdentityGuard which is… one time pads? From the Dark Reading article

Users receive Bingo-like cards with thousands of passwords on them. Since their entries are determined by when they access Treasury Direct, the passwords constantly change and make it tough for hackers to crack. Another plus: It cost only 25 cents for each card, and the cards were available in Braille for the sight-impaired.

Wow, now we’re really moving into the 21st century. Another card to carry around in my wallet, which I can use for… oh, just one thing. And it’s electronic, so I can… wait, no it’s not. On second thought, why don’t we just give me a second password which I can write down on a sticky and stick in my wallet? That’s a second factor, right?

The Post has another article on an NIH laptop stolen from someone’s car. The interesting part is that the Post points out that the laptop should have been encrypted:

The information was not encrypted, in violation of the government’s data-security policy.

At least there are policies about this now, but as we all know, most security policies aren’t followed because they’re annoying. Luckily, laptop encryption is not as difficult as it once was. TrueCrypt, SecureDoc, heck, even BitLocker, make hard drive encryption fairly easy.

The last paragraph in that story also goes on to say that personally identifiable information would not be located on laptops. I want to know how they’re going to manage that. People want to be able to work form home, they want to be able to work on the plane, or the airport. Perhaps in this specific instance, the personally identifiable information is not required for these people to do their job, but in many cases, some kind of identifying information is required. The only good option is full hard disk encryption – or at least all data directories/drives.

The MSDN documentation for CertGetCertificateChain is pretty unclear when describing how the CERT_CHAIN_TIMESTAMP_TIME flag relates to the pTime parameter. The documentation for the function can be found here.

The pTime parameter is described like this:

A pointer to a FILETIME variable that indicates the time for which the chain is to be validated. Note that the time does not affect trust list, revocation, or root store checking. The current system time is used if NULL is passed to this parameter. Trust in a particular certificate being a trusted root is based on the current state of the root store and not the state of the root store at a time passed in by this parameter. For revocation, a certificate revocation list (CRL), itself, must be valid at the current time. The value of this parameter is used to determine whether a certificate listed in a CRL has been revoked.

The value of CERT_CHAIN_TIMESTAMP_TIME is explained like this:

When this flag is set, pTime is used as the time stamp time to determine whether the end certificate was time valid. Current time can also be used to determine whether the end certificate remains time valid. All other certification authority (CA) and root certificates in the chain are checked by using current time and not pTime.

So, it would appear that when you pass in a timestamp in the pTime parameter with the CERT_CHAIN_TIMESTAMP_TIME, the chain would check the time-validity of the end certificate using the time that was passed into the function. But, this isn’t the case; in fact, that is the behavior that is exhibited when you don’t specify CERT_CHAIN_TIMESTAMP_TIME. What this flag actually does is set a requirement that the end user certificate is time-valid at both the pTime parameter as well as the current time. (This behavior was started by the MS04-011 patch. The function used to work the way you would think that it would, based on the documentation and the name of the constant). Think of it this way: the flag would make more sense were it named CERT_CHAIN_TIMESTAMP_AND_CURRENT_TIME.

Another thing to note is that the pTime parameter will only affect checking the time-validity of the end certificate in the chain; it is completely ignored when validating intermediate and root certificates, as well as during revocation checking. CAPI doesn’t have much support for verification of old signatures, mainly due to a lack of support for RFC3161 timestamps. Without secure timestamps, there is no standards-compliant way to validate older signatures, and therefore the current trust and revocation information is the only information that is useful for certificate validation.

If you want to do things in a non-standard way, you have to code around the limitations of the API – just realize that what you’re doing probably isn’t going to be all that secure. Certificates and revocation information expire for a reason.

For more information about validating aging digital signatures, see my white paper titled “Long Term Digital Signatures”, available on the Gemini Security Solutions web site.

An opinion piece worth reading from Bruce Schneier in Wired:

Security requires a particular mindset. Security professionals — at least the good ones — see the world differently. They can’t walk into a store without noticing how they might shoplift. They can’t use a computer without wondering about the security vulnerabilities. They can’t vote without trying to figure out how to vote twice. They just can’t help it.

When we hire people at Gemini Security Solutions, this mentality is something we explicitly look for. I do think this can be taught, but people with the innate hacker tendencies tend to come up with 5 vulnerabilities where an “ordinary” person might only see one or two.

via /.

Some credit card companies are giving customers credit cards with embedded RFIDs (radio frequency ID tags).

They claim this makes things faster and more secure.

Its true that, implemented correctly, RFID-enabled credit cards could provide a secure alternative to taking your card out and swiping it or handing it over to a cashier.

But right now, it seems like a few dollars is all it takes to get around their virtually non-existent security measures and extract the sensitive information embedded on the cards.

Pablos Holman did a quick demonstration on BoingBoing TV about just how easy it is…