Before Yahoo poached him to be their CISO, Alex was one of the principals behind iSEC Partners, our former arch-competitor and now sister company. He knows what he's talking about. If he says they're on top of shellshock, my money would be on him being right.
His team also recently poached Chris Rohlf, from his own company no less!, and Chris is probably one of the best vulnerability researchers working.
(I have no affiliation whatsoever with Yahoo and while I like Alex fine, we're not close friends. I'm pretty biased about Chris, though.)
This is more "vote of confidence" than your comment asked for; I'm just heading off a potentially unproductive thread at the pass. :)
This all sounds good - especially given your reputation for infosec.
However, genuine question - how does the laymen (like myself) rate infosec specialists? Imagine for a second I'm a senior exec at Target and IBN (IBM's fake arch-competitor) comes to me and says "no worries about security, we use 256-bit encryption, bank grade security, etc etc". Do I believe him?
I feel like infosec is a "I don't know what I don't know" industry and the consequences could be potentially dire.
You essentially can't evaluate that in isolation (looking at their past interactions with the infosec community may help).
It gets better: you can't even depend on the large players generally getting it right. If a large organization makes a bad decision with their first infosec hire, it's not a self-correcting problem - the next hires will be cut from the same cloth, and unless something blows up, almost nobody will know.
How much are e.g. SANS certifications worth? I subscribe to their vulnerablity emails but they push the certification programs so hard it smells a little like University of Phoenix.
I can't comment on SANS in particular, but certifications in general tend to be worthless. Receiving a certification tends to be more a matter of persistence than competence. Worse, because the higher quality applicants generally recognize the futility in it, many of them don't participate, which means you can't even assume that someone without the certificate is unqualified.
As far as I can tell the best information provided by a certificate is that you should avoid applicants who brag about them (and for applicants, avoid employers who list them as job qualifications).
That's not an accurate summary of how we hire. We don't make decisions based on the crypto challenges or Microcorruption; we use them to find people to talk to. We have a whole process that actively evaluates candidates.
In some organizations, infosec is just for show. They do it because compliance forces them to do so. In those organizations, the senior execs don't care. They only want to keep the cost down and to comply with audits. They hire managers who do that and mostly rely on legal contracts and agreements to enforce security. When they get hacked, they will pull out the report (or whatever) that states that they are XYZ compliant.
While I don't doubt that infosec is just for show in some places, you can't just say that when they get hacked, they'll just say "We're XYZ compliant" and do nothing else.
The whole point of those audits is to show that, while every company of any importance will eventually have some sort of breach/break-in/hack, the company takes all reasonable steps to prevent it and mitigate the possible effects of such an event.
Infosec isn't a fool-proof thing. There's no way to prevent everything, and all you can do is keep on top of things and take steps to ensure you're doing everything you can to protect your systems.
Twice means once for the initial bug on Wednesday, the second time with one of the "nuke the attack surface from orbit, it's the only way to be sure" patches that became available that Thursday.
This is no guarantee, of course, which is why the pen-test team that Chris Rohlf runs has to stay abreast of and continuously test the latest available exploits as well as the attempts that we see in our logs.
If you followed some common-sense advice [1], you only needed two patches: the original one as a stop-gap measure for the original RCE on September 24, and Florian's prefix-adding patch that came out shortly thereafter (but has taken some time to appear upstream).
Now, I'm a bit stumped how any obvious variant of the CVE-2014-6271 or CVE-2014-6278 RCE payloads could lead to accidental code execution somewhere else, since they generally produce a parser-breaking syntax error when executed outside an env-encoded function definition. Also, because of an unusual fixed-string prefix required to carry out the attack, there is not a lot you can really do to avoid any half-baked IDS/IPS. Anyway, for the sake of my idle curiosity, I secretly hope that Alex shares the buggy line of code, even though that's unlikely =)
There aren't '30 patches' for each system. For CentOS there have been only 2 patches as far as I can tell. Whether all of the issues have been fixed in these patches, I'm not certain. I've also made sure we're using modperl instead of cgi perl.
The 30 patches are the number of total patches on that version of bash (bash's version release cycle is major.minor.patch), not the number of patches related to shellshock.
Not knocking on you or anything, just more interested to know if all exploits have been patched against, more than the # of patches applied.