find|grep spawns two processes. find -exec grep is probably what you meant. I think something like "grep xxx $(find yyy)" should produce the same result without huge amounts of forking. Unless command line length has a practically reachable limit. I'm not sure about that.

Comparing an operating system to a development model ought to throw an exception.

Thanks for the example. My bank actually has an SMS confirmation system like you described, but it's only for "unusual" transactions. I've never triggered it, so merely transferring money to new accounts for the first time doesn't do it. Most of my payments are in the two-digit range though, and I assume they thought it would be too annoying for most customers to confirm each and every transfer.

It's just an indexed list of short codes, bank's website tells which index to use when logging in and also when doing wire transfers or other important stuff. Each of the 300 codes are used only once obviously.

Could you elaborate on the worthless systems? Is my bank's system one of those and if not, what would these systems be like exactly?

Or our Battle.net accounts, which have better security measures* than anything on your list :-)

*Stronger passwords than my online banking allows plus a one-time pad and SMS confirmation for actions such as changing passwords. My bank has a one-time pad too but from what I've gathered from comments on /. that's not as common as it should be.

You're right, and Linux actually ignores the setuid bit on shell scripts. I forgot about that earlier.

I appreciate the effort and I don't mean to be argumentative, but it's /bin/bash in the CGI script that causes the issue, not that the naive programmer launches shellshock-victim-server.pl from bash, right? My point from the start was that the interactive shell used doesn't matter. This is starting to feel a bit silly, but I'm still not sure if you're misunderstanding me or if I'm just very thick today (it's not intentional).

My point was that I don't know why human users' login shell being bash in Debian would make the system more vulnerable to remote attacks; thus I was wondering why you thought it was relevant to point out that interactive users run bash by default. Your reply didn't really clarify that. Running servers from a bash shell shouldn't cause issues by itself. Unless maybe if the server spawns another shell instance based on $SHELL instead of using /bin/sh directly?

I think it makes a big difference that Windows is made by a faceless corporation, while GNU, Linux etc. were and are developed largely by "hacker next door" types. It's understandable that Linux users who may have contributed themselves take criticism more personally and may act defensively. Also I feel there's the difference between criticizing a commercial enterprise and what's mostly a charity effort.

None of this excuses rude behavior, but generally understanding possible reasons behind rudeness helps me not take it personally.

Unless I'm badly mistaken, the default interactive shell isn't relevant in the "Shellshock" case. If an attacker has a login shell already, they need to find a setuid shell script explicitly using bash in order to gain more privileges.

I wonder if Debian's default /bin/sh being dash instead of bash reduces the attack surface somewhat. Do usual configurations of web servers (and others listed in TFA) call /bin/sh or /bin/bash directly?

Hindsight is 20/20 obviously, but it makes sense to use a shell with limited features in cases where limited features are enough (especially when remotely accessible). On the other hand, now you've got two shells with potential security issues instead of just one.

I can't think of any website I wanted to visit this year but couldn't due to adblocking. I doubt it's necessary to reconsider any time soon. Even then, I'll first look into alternative websites.

Fart apps and Windows updates could fail?! NOOOOOOOOOooooooooooooooooooo!!!!!!!

I'd like to leave any and all real world problems to others too. Any takers?