Liudvikas Bukys

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.

At Rose-Hulman Institute of Technology:

Earlier this week, a hacker infiltrated the website of a company in France, defacing the site and using it to send vulgar emails. The hacker was not a Rose-Hulman student. But through a router maintained by a Rose-Hulman student, the hacker was able to do this anonymously.

The student, senior computer science major David Yip, was maintaining a router on his computer called a Tor onion router.

There are many ways to describe this activity: exercise of freedom, negligence, lack of due diligence, accomplice or accessory to crime. Is it a social contribution or an anti-social practice? Drawing the lines is very difficult (as legislators trying to ban open access points will discover). One example of how universities do tend to have a stricter social compact than, say, ISPs.

[via Justin Mason]

While discussing the current venture capital situation, Paul Graham points out

An experienced CFO I know said flatly: “I would not want to be CFO of a public company now.”

and

This law was created to prevent future Enrons, not to destroy the IPO market. Since the IPO market was practically dead when it passed, few saw what bad effects it would have. But now that technology has recovered from the last bust, we can see clearly what a bottleneck Sarbanes-Oxley has become.

As always, read the whole thing.

Kumar, Paxson, Weaver: “Outwitting the Witty Worm: Exploiting Underlying Structure for Detailed Reconstruction of an Internet Scale Event” is a brilliant forensic analysis. Their overview:

Many Internet worms use pseudo-random numbers to scan the IP address-space. In this project, we reverse engineered the state of the pseudo-random number generator (pRNG) which the Witty worm used to generate packets. By combining our knowledge of Witty’s code with the pRNG state, we performed a detailed recreation of the worm’s spread. We were able to discover several characteristics of the infected systems, including their uptime, network access bandwidth, and number of disks. Additionally, we were able to find specific details about the worm author’s deliberate targeting of a US Military base, and determine the identity of Patient 0, the system used to launch the worm.

and there’s interesting followon discussion at SecurityFocus.

My personal log of “this could be you” security examples here wasn’t ever exhaustive, and tended to be university-centric. For those looking for a thorough view, these look like good places to keep an eye on:

• Adam Shostack’s breaches blog
• the Privacy Rights Clearinghouse chronology

At some point, the frequency will overwhelm the reporters, the readers’ eyes may glaze over, data will be available but more aggregated. Right now the California SB1798 requirement plus the high public scrutiny seem to be causing improvement in de facto standards for reporting. That will level off as companies and institutions test what they can get away with.

myNetWatchman’s SecCheck is a handy tool available as ActiveX or DOS executable. It dumps out a bunch of configuration detail from your system:

• Currently active processes
• Defined services
• Startup folder items
• Startup Registry Key contents
• Applications listening for inbound connections
• Applications with active network communications
• Active Browser Helper objects (BHOs)
• Installed ActiveX controls
• Module dump (DLLs) for all active applications

If you don’t mind trusting the executable content from myNetWatchman, it’s faster and easier than downloading a bunch of separate tools (fport, etc) to do the same thing.