Skip to main content

Posts

On aging (software)

I’m looking at an old (early 20th century) hand-crank record player that was handed down to me from my great-grandmother. It’s a simple wooden box with a spring & flywheel mechanism that spins the turntable at a somewhat constant speed, a metal needle that rides in the grooves of a record disk and transmits the vibrations onto a small metal drum, and a big metal horn that focuses the sound from the drum and directs it out into the room. The power source is a human winding a spring. The sound and amplification are purely mechanical. It’s simple. If it breaks you can take it apart, look at what’s inside, and with just a bit of tinkering you’ll probably get it to work again. If it somehow survives a few thousand years, the people from that era will look at it, figure out what is is supposed to do and with a bit of tinkering it’ll be made to work again. If one were to draw the mechanicals out on archival paper, a person from the future would be able to create a functioning replica usi…
Recent posts

Blog: Resurrect or Die?

This blog has been idle since 2012. Does anyone care?

Like many, I let this blog die. I think that’s happened for a variety of reasons, both personal and professional.

Relevance: Most of what I was posting was clearly not going to make any difference to myself or anyone else. Posts that announce [random software] has [random vulnerability] could just as well have been machine generated. The state of software security is at best, marginally better than it was a handful of years ago, and some random guy blogging about it isn’t gong to change that.

A few posts were and are still relevant. No matter what I do, I’ll maintain access to those.

Burnout: Having more than one open Oracle Sev 1’s per team member was brutal. We were in a situation where a small handful of us were working a seven-day pace for months. A few months of that and I was more than ready to back off from my immersion in technology and recuperate a bit. Hobbies got more interesting, and being able to disconnect from 24x7 …

The very four digits that Amazon considers unimportant...

"The very four digits that Amazon considers unimportant enough to display in the clear on the Web are precisely the same ones that Apple considers secure enough to perform identity verification..." Honan wrote. Four digits, when combined with my home address and bank account number were all it took for me to gain on line access to a dormant checking account at my bank and enable fund transfers. If I were fond of the various auto-pay options, there would be a dozen or so companies that would have my checking account number, any pretty much anyone in the world can find out my home address (I own a house, so it's in various public records).

Segmenting ones on line life into non-overlapping buckets seems like the best way to break the daisy chain that led to the hack and data loss. I've followed that principle. I try to maintain separate, non-overlapping e-mail addresses and passwords for any on line account that either is connected to something that could cost me mone…

In MumbleWare versions 8.2 and below, the SA password must be set to propq

An e-mail from a vendor, somewhat anonymized:

From: ****
Sent: Wednesday, April 11, 2012 08:22 AM
To: ****
Subject: MumbleWare Case 123456789


Hello ****,
Thank you for contacting MumbleWare Product Support.  I am writing to you in reference to case number 123456789 regarding your request to change your SA password. In MumbleWare versions 8.2 and below, the SA password must be set to propq. If a different password is used, MumbleWare may not be able to communicate with the database and error messages will be generated. The attached KB article references the fact that the SA password must be set to propq in MumbleWare versions 8.2 and below. The second KB article lists the steps involved in moving from MumbleWare 8.2 to 8.3.    It's only been a decade since we first asked  the obvious question "Can we change our SQL Server SA password without breaking your application".

I guess we finally can.

A letter to our Apple Account Exec

A couple of days ago myself and a colleague of mine ran into our Apple account exec.  The conversation ended up in the security space, as is probably appropriate considering Apples recent performance in that area. Our account exec quickly followed up with a request for our contact information (good), a press-release style announcement on how much more secure Safari 5.1.7 was going to be (interesting), and a month old article on how to remove Flashback (amusing).

I figured he was missing the point of our conversation. Here's my reply:

Thursday, May 10, 2012 8:31 AM ***** -

The context of our conversation was really strategic, not tactical. The short term issue of a specific malware incident isn't important. (We knew about Flashback and how to remove it  shortly after it was discovered.)

What is an interesting discussion is Apple's strategic, corporate wide attitude towards enterprise desktop security and desktop management and the question of whether or not Apple, as a…

OT: A plan.

Aaron Smith posted this story about the kindness of an NYC cab driver. It's a good read, and it reminds me of something vaguely similar that happened to be a few decades ago.

I had just moved 400 miles from home to a small town in Minnesota near where my grandfathers sister had moved in the 1930's. He didn't get to see her very often, so when I moved near her farm he had an excuse to make the trip.

The house I bought needed a ton of work, my youngest brother needed an excuse to skip high school, my grandfather needed a ride to Minnesota, so I ended up with a couple hard working helpers once weekend or so per month. Good deal for me.

One weekend my grandfather insisted on coming out to Minnesota. He had just been out a few weeks earlier, I didn't need any help and my brother wasn't enthused about another road trip.

He insisted.

They made the trip.

While he was helping me strip wallpaper that weekend, I noticed that he was hitting the nitro pills pretty regularly. H…

Apple joins the big leagues

I've been hearing 'OS X is secure' for a decade now. For a decade, I've been challenging that assertion.

The challenges to that assertion generally end up with a response of'because it's Unix' or 'because it's not Microsoft'. I don't recall 'OS X is secure' assertions being backed up by detailed explanations of anything in the kernel, operating system, development tools or coding practices that assures a higher level of security than competing operating systems, and I don't hold that a Unix history automatically ensures a more secure platform. My first forensic examinations were Unix, not Windows, and I can easily assert that the reason that we have more compromised Windows servers and desktops is because we have more Windows servers and desktops.
Unfortunately the 'OS X is more secure' fantasy has left some (or many) with the impression that they don't need to practice safe computing on Macs. It is OK to run as admi…