Category: Patching

Liveblogging Shmoocon: Patching

Patching Uncategorized No Comments

I’m at Shmoocon, and trying to liveblog a little. There’s network trouble, so it may not quite be live.

I’m at Tina Bird’s talk on patching, and she mentioned that in the Teragrid attack, the attackers were hitting supercomputer centers, and there’s some evidence that they were 1) using 0day and 2) using the big computers to attack Kerberos tickets.

Assess the criticality of a patch yourself (slide 9), but I ask how to judge an ‘exploit is in circulation.’

Network access control: Stanford scan the system vs. company install client

[Update: Shmoocon was too much fun for me to blog. Taosecurity has summarized lots of the panels here and here. I was hoping to meet Richard, but failed.]

More on Economic Analysis of Vulnerabilities

economics information security Patching Uncategorized No Comments

Dave Aitel has a new presentation (“0Days: How Hacking Really Works“) on what it costs to attack. The big cost to attackers is not vulnerability discovery, but coding reliable exploits. (There’s an irony for you: Attackers are subject to the same issues with bad software as their victims.) The presentation is in OpenOffice format only right now, so the OpenOffice Viewer (in Java) may be helpful.

[Previous posts: Towards and Economic Analysis of Vulnerabilities.]

Small Bits of Chaos: Vidal, SP2, Iraq

Liberty national security Patching Uncategorized No Comments

Gore Vidal has a few choice words about the President’s Inaugural address, at DemocracyNow.

A Russian company, MaxPatrol, has published a paper on bypassing heap and stack protection for Microsoft Windows XP with SP2.

Winterspeak has an interesting summary of Iraq:

The big bet that President Bush placed all these months ago, the bet that the root cause of Islamic Fundamentalism was the repressive, totalitarian regimes these people lived in, is being called as Iraq has elections tomorrow.

Small Bits of Chaos

information security Macintosh Patching privacy Uncategorized 1 Comment

Ryan Singel reviews Robert O’Harrow’s new book, No Place To Hide. O’Harrow covered the CAPPS-II and other privacy stories for the Washington Post.

In the spirit of the story, I’ve left the little tracking bits from Ryan’s Amazon URL. If you’d like a less tracked version, click here, or type the title into Amazon.

There’s a new security scanner called “The Attack Toolkit.” It seems to be a Nessus replacement, not a Metasploit replacement.

Securityfocus has a long article on ITIL, the Information Technology Infrastructure Library, which is a group of people bringing a lot of good thinking to IT operations and security.

SixApart, makers of the Movable Type software that powers this blog, are buying LiveJournal. My friend Jane said she thinks the merger makes me look cross-eyed. I hate her!!!!

Pete Lindstrom points to an article on risk in the Wall Street Journal on risk. (Subscriber-only, Lindstrom summarizes.)

Gizmodo reports that Bill Gates gets a blue screen onstage at CES. Can you imagine that happening to Steve Jobs?

Quick Links

economics Macintosh Patching Uncategorized No Comments

John Robb has an article at Global Guerrillas about the cost of terrorist attacks and their impact on the economic equilibria at work in cities, based on a report by the NY Fed.

A terrorism tax is an accumulation of excess costs inflicted on a city’s stakeholders by acts of terrorism.  These include direct costs inflicted on the city by terrorists (systems sabotage) and indirect costs due to the security/insurance/policy/etc. changes needed to protect against attacks.  A terrorism tax above a certain level will force the city to transition to a lower market equilibrium (aka shrink).  So, what is that level? 

Next, Ian Grigg discusses an article on corporate espionage:

… against American companies, generally by their competitors. It’s good because it is real. The threats are validated by court filings, research and surveys. This is what real security is about, determining what threats are out there, validating them and constructing economic models of their costliness. Only then can security people proceed to design economic security systems to address the threats.

I’m generally skeptical of claims of industrial espionage, but the Baseline article has six examples. Its not clear to me that’s enough to build a business case.

Finally, John Gruber has a long article at Daring Fireball on what to do before you patch your Mac, with some discussion of the superstitious, and potentially harmful advice that’s out there. Short answer: wait a day or three (gosh, where have I read that?), and backup first.

Be Careful What You Wish For, Air Force

Patching Uncategorized 1 Comment

Federal Computer Week has a story about the Air Force’s efforts to patch faster:

Officials’ ultimate goal is to have software patches implemented
across the Air Force in minutes. During the next few months, they hope
to cut the time from tens of days to just days, said Col. Ronnie
Hawkins, director of communications operations in the Office of the
Deputy Chief of Staff for Installation and Logistics.

Also in recent news, Microsoft will be providing Air Force specific windows builds. Also recently, EDS took down between 40,000 and 80,000 computers in the UK’s Department for Work and Pensions, in an attempt to roll out a patch. That’s the downside to a monoculture.

The upside is that you have far fewer configurations to test on when your builds and configurations are tightly locked down, and that saves a lot of money. If your MTTR is low because you can roll out images to an affected system, then you may be willing to take that risk. At the DWP, clearly, the MTTR was not low.

Low MTTR and fast patching shouldn’t be your only goal. Systems hardening, either by your local experts, or from companies like PiVX, Sana, or Immunix can reduce the need to patch against various attacks. I hope these companies start publishing a running list of what patches you need to install if you have their systems. (And warranting that the list is correct.)

So a low time to patch isn’t what the Air Force should be chasing: Its a low exposure time. But then, they need to balance that with expected downtime for patching. And from here, I’d just be repeating myself with what we’ve already said in the time to patch paper (PDF).

(Via ISN.)

To sleep, perchance to sleep?

Patching Uncategorized 1 Comment

After installing Apple’s latest security update, my laptop no longer goes to sleep when I close it. Is anyone else with more time experiencing this?

I am using Bernhard Baehr’s excellent Sleepwatcher, a daemon that allows you to add sleep and wakeup actions, but that hasn’t changed in a while.

(If I had more time, I’d analyze for you the nature of monthly patch packages, and how this is illustrative of one bad aspect of them: Apple makes me change a lot of software that I don’t care about in order to reasonably easily fix the software I do care about.)

How not to find vulnerabilities (2)

economics Patching Security Uncategorized 1 Comment

Pete Lindstrom has argued that we need to end the bug-hunt:

Once evaluated, neither reason provides a good foundation for continuing the practice of vulnerability seeking, but it gets much worse when we consider the consequences.

There is a rarely mentioned upside to all this bugfinding, which is that researchers use the exploit code to test defensive mechanisms. Companies like Immunix, PivX, or Sana could not accurately test their tools without exploit code. That’s not an argument for immediate release. But those zoos of exploit code are very useful.

More importantly, Lindstrom says what we should not do. He’s clearly been talking to too many security experts. I’d like to hear what we should do. More laws like the DMCA? Privately paid bug bounties? Public beheadings?

I think that Lindstrom and I are in full agreement: The current system is bad, and we’d all like to do better. I don’t think attacking the bugfinders is the right approach. We need to stem the problem where it starts. The problem starts with development languages that are unsafe at any speed. Developers aren’t trained in their use. Projects are driven to ship quickly, without good QA.

There are better ways to develop? The eXtreme Programming folks call for better test harnesses. Better modularity allows you to develop and test patches faster. Better patch management, including bullet-proof rollback, allows your customers to deploy patches at lower risk. More use of things like Stackguard automatically close off venues of attack.

I recite these things because there are better ways to do things. Those better ways make sense, and smart companies are adapting them. I’d love to see an analogous way to improve bug-hunting.

[Update: Nudecybot has waaaaaaay too much time on his hands if he catches spelling errors like that. Must be the snow.]

How not to report vulnerabilities

Patching Security Uncategorized Usability 1 Comment

This week Finjan announced that it has told Microsoft of 3, or 10, or maybe 19 issues with SP2.
Robert Lemos at CNET writes:

“We don’t want to argue with Microsoft about these things,” he said. “We found the 19 vulnerabilities, and we showed that you could take remote control of a computer.”

However, Microsoft’s Wilson took issue with Finjan’s move, contending that the software giant does not agree on how many of the flaws are real. Moreover, because the security company released the issues piecemeal, the software giant argues that it is not certain that Finjan has even named 10 vulnerabilities.

“They have been contacting us over time regarding various issues,” Wilson said. “But there is no definitive communications between Microsoft and Finjan about 10 specific issues.”

(I don’t agree that a vendor is always owed 30 days (as Lemos claims is standard.) Its a fine goal, but there are often issues that need faster response. The vulnerability clock ticks from the day the bad code is written. Software companies need to enhance their testing practices and software modularity so they can cut reliable patches faster.)

Back to the reporting side.

The Finjan press release includes no CVE names. It is now easy to reserve CVE CANdidates. Responsible researchers should do so. (There are lots of good, competing definitions of responsibility. None that I know of includes making your research harder to access and manage.)

Microsoft and Finjan can’t agree on how many issues Finjan has reported. This is slop on Finjan’s part. They may have found two routes to one issue, but there certainly shouldn’t be a 3-10-19 discrepancy. Finjan should clearly state how many issues they’ve found, roughly what they are, and when Microsoft was informed of them. Many people have issues with the detail in eEye advisories. But they are very clear on what they’ve reported.

Theme: Ephemeris.

MENU

Navigation