The Weekly Ink #13
THE WEEKLY INK
The Weekly Ink is the weekly newsletter brought to you by Duo Labs, the security research team at Duo Security, with curated links of interest in the security world to inform the community on security happenings and culture.
SHELL SHOCK EDITION
Well, we just had the opposite of a slow-news week in the security world. Between multiple bugs in bash and a rather serious signature-validation bug bug in NSS, many in the IT world are probably still running around with their hair on fire!
But, never fear: Duo Labs soldiers on, bringing you informative blog posts even as the world (figuratively) burns. This week's issue is a bit short, just to make sure you'll have plenty of time to go back and make extra sure all your servers have been patched!
In the coming days, as this bash fiasco settles down a bit, I'm sure we'll collectively do quite a bit of soul-searching on what all this means. Veracode's Melissa Elliott has already started, though, and I think there are (at least) two points here that bear extra emphasis:
- "From my perspective, bash has always existed, and I have never given any thought to where it comes from or who maintains it. It’s just there..." The so-called Shell Shock issue has a lot in common with the Heartbleed mess from earlier this year: suddenly, the world became aware of a crippling flaw - that has existed for years - in a tool that we all use. Like OpenSSL, bash has (somewhat accidentally?) become a critical piece of core infrastructure for the systems that we've come to depend upon for our lives and livelihoods. Also like OpenSSL, it's apparently a huge mess of crufty code into which few people have dared to look in a very long time. This ... isn't a recipe for rainbows and unicorns.
- Knowing what we know now, the particular feature (or "misfeature") in bash that enabled this attack - that you can define functions in environment variables and bash will parse them on startup - is mind-bogglingly stupid. After all, the software security community has known approximately forever that environment variables can be dangerous. There are those arguing that bash can't be made safe unless this entire feature is stripped out. I'm thinking, they're probably right.
For more general updates on the Shell Shocker issue, some helpful folks have set up https://shellshocker.net/, which seems to have some pretty good, up-to-date information on the bug(s), and potential remediations. Just, everyone, can we please cool it with telling people to run things along these lines:
$ curl https://example.com/script | sh
If you're wondering why I feel so strongly about this, well...
Maybe you're thinking that the curl command on https://shellshocker.net/ is actually fine, because it uses an HTTPS URL. Well, aside from questions about whether you should trust the site itself, this past week brought yet another case demonstrating how SSL and its various implementations might not protect you as well as you'd like: word came out that NSS - the Mozilla-developed SSL library - has a pretty serious signature-validation flaw that can allow attackers to forge certificates. NSS isn't only used by Mozilla, though; it's the SSL library of choice for several other browsers, along with many other miscellaneous tools and systems. One highly-relevant example: several Linux distros (e.g. RHEL/CentOS) build curl against NSS by default!
So, hide you kids, hide your wife, and update your browsers! now!
(For what it's worth, it turns out that at least one other SSL library - yaSSL - had the same weakness. However, there seems to be no evidence that e.g. OpenSSL was affected, at least in a release version...)
Yes, you read that right. John J. Escalante - chief of detectives for Chicago's police department - thinks that the new iPhone(s) might just have found a new niche. This comes as a direct result of Apple's announcement that in iOS 8, all user data will be encrypted by default. (Of course, if Chief Escalante is so fixated on Apple, maybe he missed Google's announcement that Android L will do approximately the same thing?) Now, given all that we've learned recently about mass government surveillance, I'm not going to lie: every time I hear government officials complaining that they've lost some ability to invade people's privacy on a mass scale, my knee-jerk reaction goes something like:
However, there actually are some legitimate concerns here - just, if law enforcement officials want to open a productive dialogue on ways to resolve them, I don't think this is a constructive way to start.