Hopeless Geek

Whoops.

Parse error: syntax error, unexpected T_ENDIF in /var/www/html/www.flickr.com/templates_c/ %%20^205^205F4442%%page_recent_activity.txt.php on line 167

In one line I now know Flickr uses PHP and Smarty and where they keep the files on the server’s drive. Good job, guys.

templates_c is where Smarty keeps the compiled page templates, by default.

It would appear someone in Apple is listening after all. The security issue I detailed over at Mac Geekery has been fixed in this latest security update, according to the release notes for the update. Very nice.

Big kudos to Apple for even fixing it in 10.3.8. Now I just need to see how they fixed it…

CVE-ID: CVE-2006-4404
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9,
Mac OS X v10.4.8, Mac OS X Server v10.4.8
Impact: When installing software as an Admin user, system privileges may be used without explicit authorization
Description: Admin users are normally required to authenticate before executing commands with system privileges. However, the Installer allows system privileges to be used by Admin users when installing certain packages without requiring authentication. This update addresses the issue by requiring authentication before installing software with system privileges.

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.