Thomas Ptacek | November 23rd, 2005 | Filed Under: Defenses
In the qmail security guarantee, back in 1996, Dan Bernstein attributed the success of his architecture to 7 “fundamental rules”:
Don’t treat programs and files as addresses.
Do as little as possible in setuid programs.
Do as little as possible as root.
Move seperate functions into mutually untrusting programs.
Don’t parse.
Keep it simple, stupid.
Write bug-free code.
Thomas Ptacek | November 23rd, 2005 | Filed Under: Defenses
From Saltzer ‘74:
Economy Of Mechanism (aka minimize complexity). Notable failure: ISAKMP.
Fail-Safe Default (aka default deny fail closed). Notable failure: IDS.
Complete Mediation (aka the weakest link property). Notable failure: forced browsing.
Open Design (aka Kerckhoff’s Principle, if that helps). Notable failure: DVD CSS.
Seperation of Privilege (aka authorization). Notable failure: Windows 95.
Least Privilege. Notable failure: BIND.
Least Common Mechanism (aka minimize attack surface). Notable failure: MSRPC.
Psychological Acceptability (aka usability). Notable failure: phishing.
Thomas Ptacek | November 22nd, 2005 | Filed Under: Matasano, New Findings
A commenter writes:
Just configure IPSEC on the initiator and the targets and get it over with. iSCSI CHAP is not for security, it really just for avoiding simple mistakes like attaching to the wrong target and starting doing I/O.
According to Himanshu at iSEC Partners, nobody uses IPSEC for iSCSI. It’s perceived to hurt performance, deployability, and compatibility (WinAD IPSEC doesn’t interoperate with SAN appliances). But beyond that:
Updated 11/23 from Alex’s comments
Thomas Ptacek | November 22nd, 2005 | Filed Under: Uncategorized
In the personal library of functions you take with you from project to project and job to job, what are some of the most valuable functions, data structures, or routines?
Thomas Ptacek | November 21st, 2005 | Filed Under: Bitching About Protocols, Matasano, New Findings
Richard Steinnon brokers the first substantive response to my iSCSI rant, which followed our disclosure of a game-over vulnerability in the market leader. Steinnon feels validated in his prediction from six months earlier that iSCSI would suffer security problems beyond authentication.
Steinnon’s friend at LeftHand responds, and I’m paraphrasing:
People use seperate network segments for storage.
Clients can’t see each other’s SCSI LUNs (“drive numbers”).
SCSI supports CHAP!
As long as client host never gets broken in to, iSCSI is safe.
Well, allow me to retort.
LUNs masking only works if your software is secure.
And?
I don’t know anything about LeftHand. I’d like to! Maybe they can send us a box to put through our iSCSI obstacle course. I freely concede that LeftHand may be the most secure iSCSI implementation on the planet. But we broke the market leading implementation, and those guys aren’t stupid, so let’s not take each others words for it.
At any rate, my real problem with iSCSI isn’t authentication and it isn’t worm susceptability or bad traffic. It’s the drastic increase in the threat surface. Prior to iSCSI, there were no meaningful attacks on filesystem drivers or SCSI firmware. The advent of iSCSI gives attackers new tools: adulterating filesystem metadata on the wire, in transit, and the ability to directly target SCSI drivers and firmware with malicious command blocks. Those attacks don’t really have anything to do with the iSCSI protocol; they’re about the underlying concept.
Thomas Ptacek | November 21st, 2005 | Filed Under: Industry Punditry
If your inline network security device claims to provide “virtual patching”, the box must use the actual binary patch from Microsoft to do it.
Thomas Ptacek | November 21st, 2005 | Filed Under: Uncategorized
A pre-VC-pitch playlist:
Thomas Ptacek | November 15th, 2005 | Filed Under: Industry Punditry
There is nothing intimidating or evocative about real worms. Find a better visual metaphor.
Thomas Ptacek | November 6th, 2005 | Filed Under: Uncategorized
From Eric Rescorla:
Even if you believe (which I don’t) that counties should be in the business of regulating people’s network security, there are two problems with this proposal. First, there’s no real evidence that open APs are the major threat to the security of commercial networks. After all, lots of intrusions happen over the Internet. The number of people who could potentially break into your system over the Internet vastly exceeds the number of people in the local area attached to your AP. And there’s no talk here of requiring businesses who don’t operate wireless networks to have firewalls.
Without contesting the spirit of his objection, I just want to point out that the impact to network security of the Westchester proposal is rather like that of mandatory egress filtering (outbound traffic must have plausible sources): it reduces the ability of attackers to use Westchester as a launching point for attacks on other networks.
I don’t believe that regulation will solve this problem, but it is fair to point out that open wireless APs are an important new means for attackers to get access to the Internet in the first place: much more convenient and much safer than stolen university dialup accounts.
Thomas Ptacek | November 3rd, 2005 | Filed Under: Uncategorized
From Schneier, a SANS paper on Oracle password hashing weaknesses. Long story short:
They use predictable usernames instead of random salts, making it feasable to precompute hash dictionaries.
They convert to uppercase, reducing the search space.
They use a fast crypto algorithm, rather than something like the OpenBSD Blowfish scheme, which scheme deliberately slows down hashing an individual password and trades an imperceptable per-user-login delay for a prohibitively large delay for dictionary attackers, unlike the Oracle hash, which does not.
I don’t think this paper surprises anyone (for instance, the OpenBSD scheme was novel and well-received when Neils and David Mazieres, both of whom are smarter than me, presented it a few years ago —- so why would we expect the Oracle scheme to be much better?)
So here’s my question:
Hashing weaknesses aren’t new. From experience: most proprietary hashing schemes are weak.
Dictionary attacks are popular among black-hats, so enabling information about them is not benign: presumably there’s incentive to attack the Oracle scheme because it’s been written about in pen-test books.
None of these specific vulnerabilities are new. FreeBSD had the fast-hash-construction weakness in its old MD5 scheme.
So, Peter Lindstrom, is this the kind of disclosure you believe should be outlawed?
Update 11/6: I just want to thank Peter Lindstrom his comment, which adds the phrase “it’s not a bug, just a weak implementation” to the lexicon.
Matasano is a team of internationally respected security experts who have led security efforts at @stake, Microsoft, ISS, Secure Computing, Arbor Networks, Secure Networks, Bloomberg, Sandia Labs, and others. Read more about our team and how we can help you today.
©2008 Matasano. All Rights Reserved.
