Liudvikas Bukys

How Government Wrecked the Gas Can

“Hmmm, I just hate how slow these gas cans are these days,” he grumbled. “There’s no vent on them.”

That sound of frustration in this guy’s voice was strangely familiar, the grumble that comes when something that used to work but doesn’t work anymore, for some odd reason we can’t identify.

I’m pretty alert to such problems these days. Soap doesn’t work. Toilets don’t flush. Clothes washers don’t clean. Light bulbs don’t illuminate. Refrigerators break too soon. Paint discolors. Lawnmowers have to be hacked. It’s all caused by idiotic government regulations that are wrecking our lives one consumer product at a time, all in ways we hardly notice.

The 37signals article “Exit Interview: Ask Jeeves’ acquisition of Bloglines” is an interesting retrospective look at the demise of Bloglines. Of particular interest to many of us, who followed a typical user’s path through RSS aggregators (for me, Radio Userland, Bloglines, and finally Google Reader, with dabbling in AmphetaDesk and FeedDemon).

This is interesting:

More than 10 million Americans moved from one county to another during 2008. The map below visualizes those moves. [Click on the image to go to the interactive map at Forbes.com, then: ] Click on any county to see comings and goings: black lines indicate net inward movement, red lines net outward movement.

Source: Internal Revenue Service data. The IRS only reports inter-county moves for more than 10 people, so some moves are not shown on this map.

APNIC announces:

APNIC received the following IPv4 address blocks from IANA in February 2011 and will be making allocations from these ranges in the near future: 39/8 106/8
…
Please be aware, this will be the final allocation made by IANA under the current framework and will trigger the final distribution of five /8 blocks, one to each RIR under the agreed “Global policy for the allocation of the remaining IPv4 address space“.

After these final allocations, each RIR will continue to make allocations according to their own established policies.

Security researchers successfully forge a CA certificate, allowing them to produce new certificates that will be trusted by every browser:

MD5 considered harmful today
Creating a rogue CA certificate
Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 “collision”. Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

Now that it’s been demonstrated once, it won’t be long before someone malevolent does it too. One hopes that, by then, software desupporting MD5-based signatures will have been widely distributed, and certificates containing them will have been retired.

Update: Of course, the day of doom can be postponed by getting every MD5-cert-issuing CA to immediately update their software to: (a) stop issuing MD5-based hashes, or, at least, (b) make their certificate serial numbers less predictable. The latter is a fairly small change. Is it too much to hope for?

Ole Eichhorn has written a great essay on “the lost art of desk checking,” sharing how slow and painful experiences with debugging led to habits of deliberate and careful pre-planning and checking.

My own parallel experiences: Okay, I’m doing to date myself here too. I’m also 49 years old, but didn’t start programming until Senior High. First experiences were with Basic on a Xerox Sigma 7 (thanks, Xerox), and a Wang 2200B. Not much learned there.

I learned more during summer vacations, when I paid real money to the University of Rochester to use their mainframe. I discovered that my first APL programs actually worked. I tried my hand at IBM 360 assembly language programming, but debugging was expensive – each assemble/link/run cost over $2. So I started editing the binary object decks on a keypunch instead, reducing the cost of a link/run to something under 80 cents.

While I followed the technology curve and have all the modern development environment power tools, there’s nothing like designing cleanly and understanding what’s going on. To quote Eichhorn:

To write code I just look at my screen and start typing, and to fix code, I just look at my screen some more and type some more. So now, finally, I‘m done with desk checking, right?

Wrong.

I desk check everything. Thoroughly.

And this, to me, is a major league black art which is lost to all those who didn’t have to hand-punch cards and wait a week for their deck to run. It is a lost art, but an essential art, because all the tools which make entering code and editing code and compiling code and running code faster don’t make your code better.

I’ve been helping to organize a regional security conference, the second annual Rochester Security Summit, scheduled for October 3 and 4. Good presenters, both business and technical tracks. Some seats are still open, register now!

Nicholas Carr and Om Malik find on-demand infrastructure and utility storage (e.g. Amazon S3) “particularly attractive to startups.”

Jon Udell continues to look at various ways of interconnecting users, applications, and back-ends — only some of which have been explored yet.

I particularly like the idea of (having the option for) the user being in control of the back-end repositories, offering more freedom to retrieve their data unharmed and replace application components without necessarily being at the mercy of an application vendor.

Michal Zalewski identifies a new class of attacks, that he dubs Cross Site Cooking:

There are three fairly interesting flaws in how HTTP cookies were
designed and later implemented in various browsers; these shortcomings
make it possible (and alarmingly easy) for malicious sites to plant
spoofed cookies that will be relayed by unsuspecting visitors to
legitimate, third-party servers.

While a well-coded web application should be designed to resist attacks from hostile HTTP clients, these new attacks turn every browser into a hostile HTTP client, and it’s a good bet that many web applications are hanging on a pretty thin thread of “this can’t happen” assumptions, soon to be violated. Expect a large number of embarrassing vulnerability reports to ensue.

[via http://del.icio.us/emergentchaos/new.attack.class%3F]

I am enjoying the series of articles on business growth and fraud at the Financial Cryptography web site.
The overall theme is that, whatever level of technical perfection you achieve in a money-handling system,
things really only get interesting once the business takes off — at which point an equilibrium is reached based both on what you implemented and on how much it’s worth attacking.
The first article started the series a bit slow and abstract; for me, I like details.
The latest installment, the most concrete so far, is a case study regarding e-Gold, with some bonus comments regarding WebMoney. Note that even without technical flaws, your business is still affected by attacks on the whole business ecology (much of it out of your direct control): partners, customers, complementary businesses, reputation mongers.