The primary way in which people use OpenSSL is to secure client-server connections on a network using the SSL or TLS protocols. Most people actually use OpenSSL insecurely when they do their client-server security.
Additionally, OpenSSL is a general-purpose cryptography library, and people use that library to build other security protocols and solutions. For example, the OpenSSH project uses the OpenSSL library to implement the SSH protocol.
There are four buffer overflow problems and one denial-of-service problem. Buffer overflow problems occur when a C or C++ program is hard-wired to handle a particular amount of data, but a malicious user passes more data to that program. In these languages, the extra data will often go somewhere that can have a disastrous effect. How do they compare with past vulnerabilities in OpenSSL?
This is the first severe problem with OpenSSL itself in its nearly four-year history. The only other known problem with the library came to light about a year ago, and it wasn't a concern for most applications. However, there have been a few minor problems with the SSL and TLS protocols themselves. The buffer overflow problems are far easier to exploit than the protocol problems. Additionally, the OpenSSL interface does leave the burden of performing valid authentication largely to the end user, so most applications that use OpenSSL use it in a way that's insecure. However, this is not due to a flaw in the library itself. How severe are they?
The denial-of-service problem I don't consider to be a big issue. Most programs written in C or C++ have denial-of-service problems. As for the four buffer overflow problems: The biggest problem that affects a whole lot of people is every OpenSSL user using SSL version 3. Everybody needs to upgrade for this reason. Another problem affects software using version 2 of the SSL protocol. That version of the protocol is quite old, with security problems inherent in the protocol. Most of the world seems to have migrated to SSL version 3 or TLS version 1 (the successor to SSL version 3). A third problem only affects beta software, and then only beta software with Kerberos enabled. Kerberos itself is fairly rare. Plus, people who use beta software tend to be good about upgrading. Therefore, I'd say this isn't much of a problem.
The last problem only affects people running on 64-bit hardware such as Alphas or the Itanium, which are very few people.Will these vulnerabilities tarnish the image of OpenSSL?
I don't think these vulnerabilities will hurt the image of OpenSSL. First, most software systems have security vulnerabilities in them. It's hard to completely eliminate security problems. Despite the conventional wisdom, switching from C to Java doesn't even manage to solve the problem, in part because so many security problems are architectural flaws in the system that are independent of the language.
Second, the important vulnerabilities were found and fixed by the OpenSSL team themselves, because they're doing a manual security audit. Doing manual security audits is a long, tedious and expensive task, but it can be highly effective if done by the right kind of experts. Security audits help build confidence -- look at the OpenBSD project, which is believed to be a highly secure operating system. They've built their reputation solely on code auditing. That said, the full code audit of OpenSSL that is in progress is a vast task. I expect as that project continues, other bugs will come to light.Would someone have to be very technically savvy to exploit them?
It wouldn't require a lot of skill to exploit these vulnerabilities. An individual with talent will create an exploit code for these problems. That code will then be distributed in the "cracker underground," making it easy for nefarious high school students with limited technical knowledge to exploit these problems.