Archive for the ‘security’ Category

Target pushback

Friday, December 27th, 2013

In light of the recent, rather public, computer security failure, I stared at the error message before me.   The Ultraviolet people had announced that they are finally ready to let people register their DVD’s from home, using one of their partners’ programs.  Sounds like awesomsauce; I’d get to put all the DVD’s into less accessible storage, but still have easy, legit, access to the content on the go.  One of the three partners is a Best Buy project, CinemaNow, and I know they need all the help they can get, so I figure I’ll give it a shot.  Which is how we got to here.  Seems they couldn’t be bothered to sign their code, and the latest OSX update flat out refuses to let you run unsigned code, without mucking about in preferences.

I could make the change, easily enough, but it doesn’t seem like I should have to.  Best Buy should be fully capable of hiring developers capable of the minimal effort of registering with Apple.  That they are unwilling, or unable, to accomplish this underlines the woeful state of computer security as a proactive way of working.  The developers at Best Buy are willing to put the end user at risk, even though they should be well aware of how easy it is to trick people into downloading from the wrong place, and just how potentially devastating the results can be.  If there is justice in the universe, someone will install CinemaNow on a computer inside their firewall, and then accidentally install some malware that would have been prevented, if they hadn’t turned off the safety features of the OS, and it costs them twice as much as Target’s losses end up being.

 

Filing a FOIA

Thursday, August 1st, 2013

The other day, I dropped a hard drive and lost everything on it.  I was in despair, until it occurred to me, I can file a FOIA request with the NSA; they probably have my data backed up already.

Windows 8 Store “report app” broken

Monday, July 8th, 2013

It appears the facility for reporting fraudulent apps to Microsoft is broken, and the scammers are jumping all over it.  Currently the New Releases section is dominated by five-buck apps that act as wrappers for well known free software, like iTunes.  But you can’t report them, because the “Report app” feature is broken, and just says “There’s a problem completing your request.  Please try again later.”

Given the small number of apps in the store, that the majority are obviously frauds and scams says terrible things about the review process in place at Microsoft.  I certainly wouldn’t trust any app from their ‘store’ on a  device that carried personal information.  It seems obvious that the persons in charge of reviewing items for the Windows 8 store only care about quantity of apps in the store, and nothing for safety, security, or value.

Trading theft for robbery?

Monday, June 17th, 2013

In frustration at having to wait and pay for OnTrac to keep leaving packages in easily stolen-from locations, I’m giving Amazon’s locker service a try this time around.  Of course I wonder if I’m not just trading impersonal theft, for direct robbery, since now I’ll have to walk home with the packages.

I’m sure running will be good for my knee =p

Physical access == pownership

Thursday, December 27th, 2012

One of the key lessons of computer security is that physical access is important.

We are preparing for moving to a new office, in the new year.  A contractor has been tasked with finding the owners of all the miscellaneous boxes we have scattered about.  He was getting stuck on one of the Sparc Solaris 8 machines, with none of the typical root passwords working.  I showed him how, with a copy of the OS cdrom, it is trivial to reset the root password.  The hardest part is identifying which disk slice to mount, when you are in single-user mode, and that’s more of a tedious task of try until it works, than any sort of actual though or research.

Accidental solution

Wednesday, September 19th, 2012

I’m trying to debug a problematic interaction, between our software, and SELinux on RHEL6. Under default SELinux=enforcing configurations, our server fails with

Error while loading shared libraries : /usr/lib/xxxx : cannot enable executable stack as shared object requires

This is a known issue with how one of our modules is built, that isn’t scheduled to be addressed in the near future (the part that requires changing has a lengthy government certification processes, we want all changes to this area done at the same time to limit the number of times we have to certify). It’s been fixable in RHEL5 with a simple chcon -t textrel_shlib_t /usr/lib/xxxx.

But for some reason, while the same command gives no errors back, it also doesn’t prevent the problem that keeps us from running, under RHEL6.

One of the many suggestions for fixing or debugging the issue was to build a custom policy using audit2allow, and deal with it that way. Basically, you set your SELinux machine to permissive, do the offending operation, and them take the errors that it generated-but-ignored, build a policy with them, and then you can set your box back to enforcing, add the policy, and bobsuruncle. So I bring up /etc/selinux/config in my handy editor, but because I’m distracted by other things at work, I don’t notice there are two configurable values in the file, and instead of changing SELINUX, I changed SELINUXTYPE. Which is where things get odd.

According to the docs, the only valid values for SELINUXTYPE are targeted and mls, but I set it to permissive. I didn’t notice this, do my product install, and everything works, as expected. I go to set the config file back to default values, at which point I notice my error. Hrm, I think to myself. Looking in /var/log/audit/audit.log, there aren’t any errors for audit2allow to work off of. I put the config back to default, reboot the box, and miraculously, things are still working.

It’s hard to feel like I’ve really fixed the problem, but it sure doesn’t seem to still be occurring, so….

Fidelity account insecurity

Tuesday, June 5th, 2012

I got an email from Fidelity, saying they were having problems snail-mailing me something, and to check my account profile. So, I login and discover that indeed, of the three employer-specific accounts under my name, two of them had the wrong address. Updating the one for the company that doesn’t exist anymore was a piece of cake. But updating the address for the company that does still exist, but which I am not currently employed, has been a task seemingly far more annoying than it should be. Which is when I discovered what seems like a serious security flaw to me; to update the mailing address for the semi-defunct account, they tell me to call an 800-number, which prompts me for my username or SSN, and my password. I dunno about you, but I sure as heck don’t use passwords only made up of digits, and they don’t accept such unsafe passwords on the website, so presumably they are expecting you to flatten your alphanumeric password into the numeric overlay of the 12-key phone pad, ie “dog” == “364”, which is where I get livid, because that means they’ve basically reduced the attack surface for an account by more than 75%. See “dog” isn’t the only password you could validate against for “364”, it also covers “fog”, “eog”, “do4”, etc.

Oh well, it isn’t the stupidest thing I’ve seen today.