61–70 of 296 posts
Earlier quoted context omitted.
No, the WAF is not included in the free plan.
Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.
Earlier quoted context omitted.
Are you running an HTTP or SSH server that faces the public? If so you need to update or take mitigation steps ASAP. If not you can wait until apple patches.
I'm reluctant to add to uncertainty, but I'm not sure these are the only concerns. Many Linux systems execute shell scripts via bash after acquiring a DCHP address, and would be vulnerable if someone took over the DHCP servers in, say, a co-working space, cafe or airport and maliciously configured them. I'm not 100% sure if Mac OS X (or iOS) use shell scripts for post-assignment configuration. The short answer is to…
Edit: just saw https://news.ycombinator.com/item?id=8367086 - may look into that a little more.
Earlier quoted context omitted.
Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.
I'm going to bring it up internally, but don't hold your breath.
EDIT after OP's edit.
Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay.
EDIT2 after clarification downthread, previous edit is to be disregarded.
Is there a (low volume) mailing list that would have alerted me to both this and Heartbleed?
In another thread, I saw that this was an easy check to see if your bash was affected: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get "busted" back, then you're affected...which is what I get with Mac OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been patched in awhile...I don't get the error...Er, why is that? I thought this pretty much affected every bash since 25 year…
Debian-based systems use dash instead of bash for /bin/sh. But if you have scripts that explicitly use bash, you are still at risk.
But then I tried this command and it echoed "vulnerable". env var='() { ignore this;}; echo vulnerable' bash -c /bin/true
Can anyone explain what I should do on OSX? I've heard that replacing /bin/bash with a newer version of bash from homebrew or even zsh will work but is that going to break anything that assumes 3.2 bash??
I've been running upgraded bash - and more recently, just zsh, in OSX for years. It has never broken anything here. I think the risk of breaking something is outweighed by the risk of exploit.
There's no way that this bug could affect even a fraction of the number of users Heartbleed did. The number of affected machines is probably 1/10000th that of heartbleed, and heartbleed exposed hundreds of millions of users, the SSL keys of servers, etc to attack. The fact that legacy CGI scripts are the only attack vector being discussed right now is proof enough of how outdated this bug is. Keep in mind that hacker…
cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it seems down right now. Since cPanel is designed for people without system administration experience, it's unlikely they will be patched in a timely manner too. All the CGI scripts are in known s…
Of course it's possible that other CGI apps will execute a shell at some point, and that there's bound to be plenty of servers that are exploitable. But the number of SSL-bearing sites, and the sheer number of users (I mean, hundreds of millions, at least) that were exposed due to such gigantic sites having a huge hole for so long, meant that virtually everyone's personal information was vulnerable, immediately, to say nothing of stealing SSL keys.
This is definitely a serious bug. Any remote code execution is a top priority. But i've never seen a bug like Heartbleed before, and it's unlikely we ever will again, as (hopefully?) it will change the way forward services are deployed to implement proper memory protection between transport and application layers. Compared to exposing the personal information (and secured keys) of so many users and domains, just executing code on miscellaneous servers seems cute in comparison.