Entries Tagged "vulnerabilities"

Page 41 of 42

Sybase Practices Dumb Security

From Computerworld:

A threat by Sybase Inc. to sue a U.K.-based security research firm if it publicly discloses the details of eight holes it found in Sybase’s database software last year is evoking sharp criticism from some IT managers but sympathetic comments from others.

I can see why Sybase would prefer it if people didn’t know about vulnerabilities in their software—it’s bad for business—but disclosure is the reason companies are fixing them. If researchers are prohibited from publishing, then software developers are free to ignore security problems.

Posted on April 1, 2005 at 1:24 PM • View Comments

Secrecy and Security

In my previous entry, I wrote about the U.S. government’s SSI classification. I meant it as to be an analysis of the procedures of secrecy, not an analysis of secrecy as security.

I’ve previously written about the relationship between secrecy and security. I think secrecy hurts security in all but a few well-defined circumstances.

In recent years, the U.S. government has pulled a veil of secrecy over much of its inner workings, using security against terrorism as an excuse. The Director of the National Security Archive recently gave excellent testimony on the topic. This is worth reading both for this general conclusions and for his specific data.

The lesson of 9/11 is that we are losing protection by too much secrecy. The risk is that by keeping information secret, we make ourselves vulnerable. The risk is that when we keep our vulnerabilities secret, we avoid fixing them. In an open society, it is only by exposure that problems get fixed. In a distributed information networked world, secrecy creates risk—risk of inefficiency, ignorance, inaction, as in 9/11. As the saying goes in the computer security world, when the bug is secret, then only the vendor and the hacker know—and the larger community can neither protect itself nor offer fixes.

Posted on March 9, 2005 at 7:46 AM • View Comments

Flaw in Winkhaus Blue Chip Lock

The Winkhaus Blue Chip Lock is a very popular, and expensive, 128-bit encrypted door lock. When you insert a key, there is a 128-bit challenge/response exchange between the key and the lock, and when the key is authorized it will pull a small pin down through some sort of solenoid switch. This allows you to turn the lock.

Unfortunately, it has a major security flaw. If you put a strong magnet near the lock, you can also pull this pin down, without authorization—without damage or any evidence.

The worst part is that Winkhaus is in denial about the problem, and is hoping it will just go away by itself. They’ve known about the flaw for at least six months, and have done nothing. They haven’t told any of their customers. If you ask them, they’ll say things like “it takes a very special magnet.”

From what I’ve heard, the only version that does not have this problem is the model without a built-in battery. In this model, the part with the solenoid switch is aimed on the inside instead of the outside. The internal battery is a weak spot, since you need to lift a small lid to exchange it. So this side can never face the “outside” of the door, since anyone could remove the batteries. With an external power supply you do not have this problem, since one side of the lock is pure metal.

A video demonstration is available here.

Posted on March 2, 2005 at 3:00 PM • View Comments

Pirated Windows to Remain Unpatched

From the Associated Press:

Microsoft Corp. plans to severely curtail the ways in which people running pirated copies of its dominant Windows operating system can receive software updates, including security fixes.

The new authentication system, announced Tuesday and due to arrive by midyear, will still allow people with pirated copies of Windows to obtain security fixes, but their options will be limited. The move allows Microsoft to use one of its sharpest weapons—access to security patches that can prevent viruses, worms and other crippling attacks—to thwart a costly and meddlesome piracy problem.

I’ve written about this before. Unpatched Windows systems on the Internet are a security risk to everyone. I understand Microsoft wanting to fight piracy, but reducing the security of its paying customers is not a good way to go about it.

Posted on February 17, 2005 at 8:00 AM • View Comments

Unicode URL Hack

A long time ago I wrote about the security risks of Unicode. This is an example of the problem.

Here’s a demo: it’s a Web page that appears to be www.paypal.com but is not PayPal. Everything from the address bar to the hover-over status on the link says www.paypal.com.

It works by substituting a Unicode character for the second “a” in PayPal. That Unicode character happens to look like an English “a,” but it’s not an “a.” The attack works even under SSL.

Here’s the source code of the link: http://www.p&amp#1072;ypal.com/

Secuna has some information on how to fix this vulnerability. So does BoingBoing.

Posted on February 16, 2005 at 9:17 AM • View Comments

Flying on Someone Else's Airline Ticket

Slate has published a method for anyone to fly on anyone else’s ticket.

I wrote about this exact vulnerability a year and a half ago.

The vulnerability is obvious, but the general concepts are subtle. There are three things to authenticate: the identity of the traveler, the boarding pass, and the computer record. Think of them as three points on the triangle. Under the current system, the boarding pass is compared to the traveler’s identity document, and then the boarding pass is compared with the computer record. But because the identity document is never compared with the computer record—the third leg of the triangle—it’s possible to create two different boarding passes and have no one notice. That’s why the attack works.

Posted on February 8, 2005 at 9:11 AM • View Comments

Bank Mandates Insecure Browser

The Australian bank Suncorp has just updated its terms and conditions for Internet banking. They have a maximum withdrawal limit, hint about a physical access token, and require customers to use the most vulnerability-laden browser:

“suitable software” means Internet Explorer 5.5 Service Pack 2 or above or Netscape Navigator 6.1 or above running on Windows 98/ME/NT/2000/XP with anti-virus software or other software approved by us.

Posted on February 7, 2005 at 8:00 AM • View Comments

Automobile Virus

SC Magazine is reporting on a virus that infects Lexus cars:

Lexus cars may be vulnerable to viruses that infect them via mobile phones. Landcruiser 100 models LX470 and LS430 have been discovered with infected operating systems that transfer within a range of 15 feet.

It seems that no one has done this yet, and the story is based on speculation that a cell phone can transfer a virus to the Lexus using Bluetooth. But it’s only a matter of time before something like this actually works.

Posted on February 2, 2005 at 8:00 AM • View Comments

Microsoft RC4 Flaw

One of the most important rules of stream ciphers is to never use the same keystream to encrypt two different documents. If someone does, you can break the encryption by XORing the two ciphertext streams together. The keystream drops out, and you end up with plaintext XORed with plaintext—and you can easily recover the two plaintexts using letter frequency analysis and other basic techniques.

It’s an amateur crypto mistake. The easy way to prevent this attack is to use a unique initialization vector (IV) in addition to the key whenever you encrypt a document.

Microsoft uses the RC4 stream cipher in both Word and Excel. And they make this mistake. Hongjun Wu has details (link is a PDF).

In this report, we point out a serious security flaw in Microsoft Word and Excel. The stream cipher RC4 [9] with key length up to 128 bits is used in Microsoft Word and Excel to protect the documents. But when an encrypted document gets modified and saved, the initialization vector remains the same and thus the same keystream generated from RC4 is applied to encrypt the different versions of that document. The consequence is disastrous since a lot of information of the document could be recovered easily.

This isn’t new. Microsoft made the same mistake in 1999 with RC4 in WinNT Syskey. Five years later, Microsoft has the same flaw in other products.

Posted on January 18, 2005 at 9:00 AM • View Comments

1 … 39 40 41 42

Sidebar photo of Bruce Schneier by Joe MacInnis.