Oh boy, this is bad. This is real bad.

BoingBoing reader Steve Parkinson has discovered a customer data security hole in the automated phone care system for Sprint Wireless.

Here’s how it works. You dial a certain toll-free Sprint customer service line (doesn’t matter what number you’re dialing from), then punch in the cellphone number of a Sprint Wireless subscriber (not necessarily yours). The Sprint voice-bot reads back to you the full name and street address of the accountholder associated with that number. Could be you, could be someone else.

Boing Boing: Security blunder: Sprint Wireless leaks customer data

The Guardian is running an article detailing how two students may be expelled for demonstrating to the university the laxness of their security (complete and total break-in within seven minutes, it would appear). The article goes into detail, taking the side of the student, on how Oxford is trying to intimidate the students rather than actually deal with the problem.

It would appear to me that any institution that maintains detailed financial records, enough for identity theft, and also charges the person whose records are stored a significant amount of money each year (surpassing the average annual income) would have a moral obligation (if not legal) to spend exactly as much money as needed to protect that data with exactly the amount of security it demands. Oxford seems to think differently as they cite cost as the reason they don’t have good security for the financial and academic records of their thousands of students. Piss-poor excuse, I say.

2lmc spool – Tevanian should resign

A thought. Why can’t the mounting point be under a salted folder name? /Volumes/<randmom>/<name>, instead of /Volumes/<name>?
some explanation – Every exploit I’ve seen relies on knowing where a file is after you’ve made the user mount the dmg. If you hide this information, half the exploits go away.
This doens’t solve the registering of new url handlers issue, of course.

Because the proper solution is to not mount it in the first place, rather than obfuscate the mounting location. And, again, registering new protocol handlers is not a problem, a bug, or a security failure; it is, quite literally, a feature and a product of intended design.

There’s been a lot of noise about the URI-based security problems in Mac OS X over the past week, and there’s been a lot of misconception about them as well. Daring Fireball has a nice long article that goes into a fair amount of detail about how all this works. I link to it mainly because I don’t feel like writing all that if it’s already been written, so go read that first if you haven’t.

There are many misconceptions so far about all this, especially concerning which parts of Mac OS X have problems. Unsanity believes it’s the URI handler itself and has even gone as far as to write a very annoying program to intercept all “odd” URI requests. This is an incorrect assumption.

URIs are not the problem, the problem is what happens when they’re used. As I’ve stated before, assigning blame to the URI handler (which includes the auto-registration of URIs) this is akin to saying the Finder is insecure because it lets you open virus-infected Word files without a warning. URIs are a way of opening files, some just happen to be remote. The proper solution does not exist at that layer, and Paranoid Android is a “solution” at that layer.

The problem is that there are programs accepting input and immediately trusting it. This is a huge programming no-no. Because this little mess involves at least four distinct layers of the OS, I need to go over which ones are really problematic, and which layer to fix to clear up some of this mess less we get another hack that purports to solve the world’s ills that is just another red herring.

Unsanity is just a little bit unsane as of late. After it was discovered that the help: URI handler could trigger scripts mounted on disks with the disk: URI handler, they went and claimed a security problem with automatic registration of URI handlers via Launch Services.

The idea is that a program has a property list file that tells Launch Services which files it can open and which URI handlers it supports. This enables one to, for example, install Safari and have it handle http: requests and open .html files as well, without configuration from the user. This is pretty standard stuff. So the “exploit” is to install a program (using disk: as before) and then call the URI handler from a META tag refresh on a web page.

This is not a bug or security problem with Launch Services. This is a bug with DiskImageMounter (the program that transparently mounts disk images for the Finder, and is the default handler of the disk: and disks: protocols). The same thing needs to happen for this program as happened for Help Viewer: if the calling program is not itself (or in this case, Finder) then either error out or ask for permission.

Having been a “pro-level” user of the OS since System 6 and a developer since 8.5, I’ve paid close attention to the help technologies in the OS as they came and went. Some were pure genius, others not so much. When I look back on the many, many ways Apple’s provided help to the user over the years, I can easily see how this recent help attack issue came to be and why no one paid much attention to it until someone realized it could be used for ill. It’s been used for so many things that were constructive that few, if any, ever thought about using it destructively.

So, to see how and why this could have made it out the door, let’s look at Apple’s help technologies over the past ten years or so.

There’s a little-known fact about computer users that the media overlooks now and again, and it’s ever-so-obvious that the MacWord/TechWorld staff writers have ignored it once again. See, for there to be real security on a computer, a user cannot be stupid. The computer can only do half the work needed to make itself secure; the user must do the other half. The reason for this is that a computer exists to do things we tell it to do, and if we tell it to, oh, I don’t know, run a Trojan Horse then it will run the Trojan horse. There’s nothing in the system that will say “Hey! This is a Trojan horse!” nor can there be. It’s a program, you told it to run it, and that’s that.

Is it a security hole? Absolutely. It’s not a security hole on the computer’s side, however, but one on the user’s side. If you don’t obtain software straight from the vendor’s website then don’t trust it. It’s that simple. Can software delete everything on your hard drive? Sure it can, even on a Mac. I could whip up an Installer package in about ten minutes that would act like it was installing so-and-so software and then just wipe the hard drive after you give the password.

Don’t install software you aren’t sure of the authenticity of. I thought that was obvious, but it seems that there are still a large number of idiots in the world, and at least a few of them are working for tech magazines spreading FUD. You are responsible for your computer, not the other way around. Remember that.

Binary works great some times. Lights can be on or off, doors can be open or closed, a fan can be on or off. Yet, there are times we want a dimmed light, or a cracked door, or a light breeze as well. This is something that makers of consumer electronics have come to see over time as well.

We have actual knobs for volume, bass, and treble on (decent) radios. There’s grades of adjustments to video devices for brightness and color. There’s a way to grade most things in our lives because sometimes we just don’t need all of everything done in one way.

Apple usually sees this. We don’t want all our files compressed, of course, so we can compress those we want. We don’t want all our files in one place in our homes, so we have some default media folders for basic organization. We want to have different brightness for different environments, so the new PowerBooks handle that skillfully and change the screen brightness to suit the ambient light. Very smart stuff, generally.

It amazes me, then, that FileVault was setup in a binary fashion. All or nothing. How silly. How silly is it to encrypt my iPhotos? My iMovies? My web cache? Sure, some of those items matter (particularly the web cache, for some ) but, in general, it doesn’t. What matters are my documents and my mail. That’s it.

USATODAY.com – Microsoft studies browser flaw that may aid ID theft

Microsoft (MSFT) is investigating whether to patch a flaw in Internet Explorer that makes it easier for scam artists to commit identity theft.

Microsoft is investigating whether to patch a flaw in IE that makes it easier for scam artists to commit identity theft.

They’re thinking of fixing a bug that helps scam artists commit a crime. They’re just thinking about it.

And people were upset over that silly DHCP thing?