Entries Tagged "vulnerabilities"

Page 47 of 50

Oracle's Password Hashing

Here’s a paper on Oracle’s password hashing algorithm. It isn’t very good.

In this paper the authors examine the mechanism used in Oracle databases for protecting users’ passwords. We review the algorithm used for generating password hashes, and show that the current mechanism presents a number of weaknesses, making it straightforward for an attacker with limited resources to recover a user’s plaintext password from the hashed value. We also describe how to implement a password recovery tool using off-the-shelf software. We conclude by discussing some possible attack vectors and recommendations to mitigate this risk.

Posted on November 3, 2005 at 1:20 PM • View Comments

Liabilities and Software Vulnerabilities

My fourth column for Wired discusses liability for software vulnerabilities. Howard Schmidt argued that individual programmers should be liable for vulnerabilities in their code. (There’s a Slashdot thread on Schmidt’s comments.) I say that it should be the software vendors that should be liable, not the individual programmers.

Click on the essay for the whole argument, but here’s the critical point:

If end users can sue software manufacturers for product defects, then the cost of those defects to the software manufacturers rises. Manufacturers are now paying the true economic cost for poor software, and not just a piece of it. So when they’re balancing the cost of making their software secure versus the cost of leaving their software insecure, there are more costs on the latter side. This will provide an incentive for them to make their software more secure.

To be sure, making software more secure will cost money, and manufacturers will have to pass those costs on to users in the form of higher prices. But users are already paying extra costs for insecure software: costs of third-party security products, costs of consultants and security-services companies, direct and indirect costs of losses. Making software manufacturers liable moves those costs around, and as a byproduct causes the quality of software to improve.

This is why Schmidt’s idea won’t work. He wants individual software developers to be liable, and not the corporations. This will certainly give pissed-off users someone to sue, but it won’t reduce the externality and it won’t result in more-secure software.

EDITED TO ADD: Dan Farber has a good commentary on my essay. He says I got Schmidt wrong, that Schmidt wants programmers to be accountable but not liable. Be that as it may, I still think that making software vendors liable is a good idea.

There has been some confusion about this in the comments, that somehow this means that software vendors will be expected to achieve perfection and that they will be 100% liable for anything short of that. Clearly that’s ridiculous, and that’s not the way liabilities work. But equally ridiculous is the notion that software vendors should be 0% liable for defects. Somewhere in the middle there is a reasonable amount of liablity, and that’s what I want the courts to figure out.

EDITED TO ADD: Howard Schmidt writes: “It is unfortunate that my comments were reported inaccurately; at least Dan Farber has been trying to correct the inaccurate reports with his blog. I do not support PERSONAL LIABILITY for the developers NOR do I support liability against vendors. Vendors are nothing more then people (employees included) and anything against them hurts the very people who need to be given better tools, training and support.”

Howard wrote an essay on the topic.

Posted on October 20, 2005 at 5:19 AM • View Comments

The Keys to the Sydney Subway

Global secrets are generally considered poor security. The problems are twofold. One, you cannot apply any granularity to the security system; someone either knows the secret or does not. And two, global secrets are brittle. They fail badly; if the secret gets out, then the bad guys have a pretty powerful secret.

This is the situation right now in Sydney, where someone stole the master key that gives access to every train in the metropolitan area, and also starts them.

Unfortunately, this isn’t a thief who got lucky. It happened twice, and it’s possible that the keys were the target:

The keys, each of which could start every train, were taken in separate robberies within hours of each other from the North Shore Line although police believed the thefts were unrelated, a RailCorp spokeswoman said.

The first incident occurred at Gordon station when the driver of an empty train was robbed of the keys by two balaclava-clad men shortly after midnight on Sunday morning.

The second theft took place at Waverton Station on Sunday night when a driver was robbed of a bag, which contained the keys, she said.

So, what can someone do with the master key to the Sydney subway? It’s more likely a criminal than a terrorist, but even so it’s definitely a serious issue:

A spokesman for RailCorp told the paper it was taking the matter “very seriously,” but would not change the locks on its trains.

Instead, as of Sunday night, it had increased security around its sidings, with more patrols by private security guards and transit officers.

The spokesman said a “range of security measures” meant a train could not be stolen, even with the keys.

I don’t know if RailCorp should change the locks. I don’t know the risk: whether that “range of security measures” only protects against train theft—an unlikely scenario, if you ask me—or other potential scenarios as well. And I don’t know how expensive it would be to change the locks.

Another problem with global secrets is that it’s expensive to recover from a security failure.

And this certainly isn’t the first time a master key fell into the wrong hands:

Mr Graham said there was no point changing any of the metropolitan railway key locks.

“We could change locks once a week but I don’t think it reduces in any way the security threat as such because there are 2000 of these particular keys on issue to operational staff across the network and that is always going to be, I think, an issue.”

A final problem with global secrets is that it’s simply too easy to lose control of them.

Moral: Don’t rely on global secrets.

Posted on September 1, 2005 at 8:06 AM • View Comments

Bluetooth Spam

Advertisers are beaming unwanted content to Bluetooth phones at a distance of 100 meters.

Sure, it’s annoying, but worse, there are serious security risks. Don’t believe this:

Furthermore, there is no risk of downloading viruses or other malware to the phone, says O’Regan: “We don’t send applications or executable code.” The system uses the phone’s native download interface so they should be able to see the kind of file they are downloading before accepting it, he adds.

This company might not send executable code, but someone else certainly could. And what percentage of people who use Bluetooth phones can recognize “the kind of file they are downloading”?

We’ve already seen two ways to steal data from Bluetooth devices. And we know that more and more sensitive data is being stored on these small devices, increasing the risk. This is almost certainly another avenue for attack.

Posted on August 23, 2005 at 12:24 PM • View Comments

Xbox Security

Interesting article: “The Hidden Boot Code of the Xbox, or How to fit three bugs in 512 bytes of security code.”

Microsoft wanted to lock out both pirated games and unofficial games, so they built a chain of trust on the Xbox from the hardware to the execution of the game code. Only code authorized by Microsoft could run on the Xbox. The link between hardware and software in this chain of trust is the hidden “MCPX” boot ROM. The article discusses that ROM.

Lots of kindergarten security mistakes.

Posted on August 10, 2005 at 1:00 PM • View Comments

Stealing Imaginary Things

There’s a new Trojan that tries to steal World of Warcraft passwords.

That reminded me about this article, about people paying programmers to find exploits to make virtual money in multiplayer online games, and then selling the proceeds for real money.

And here’s a page about ways people steal fake money in the online game Neopets, including cookie grabbers, fake login pages, fake contests, social engineering, and pyramid schemes.

I regularly say that every form of theft and fraud in the real world will eventually be duplicated in cyberspace. Perhaps every method of stealing real money will eventually be used to steal imaginary money, too.

Posted on August 10, 2005 at 7:36 AM • View Comments

New Windows Vulnerability

There’s a new Windows 2000 vulnerability:

A serious flaw has been discovered in a core component of Windows 2000, with no possible work-around until it gets fixed, a security company said.

The vulnerability in Microsoft’s operating system could enable remote intruders to enter a PC via its Internet Protocol address, Marc Maiffret, chief hacking officer at eEye Digital Security, said on Wednesday. As no action on the part of the computer user is required, the flaw could easily be exploited to create a worm attack, he noted.

What may be particularly problematic with this unpatched security hole is that a work-around is unlikely, he said.

“You can’t turn this (vulnerable) component off,” Maiffret said. “It’s always on. You can’t disable it. You can’t uninstall.”

Don’t fail to notice the sensationalist explanation from eEye. This is what I call a “publicity attack” (note that the particular example in that essay is wrong): it’s an attempt by eEye Digital Security to get publicity for their company. Yes, I’m sure it’s a bad vulnerability. Yes, I’m sure Microsoft should have done more to secure their systems. But eEye isn’t blameless in this; they’re searching for vulnerabilities that make good press releases.

Posted on August 5, 2005 at 2:25 PM • View Comments

1 … 45 46 47 48 49 50

Sidebar photo of Bruce Schneier by Joe MacInnis.