A better test might be to place the phone on thick foam, then roll a soft bar over it, applying a constant force. Then rotate the phone one degree, and repeat. Continue repeating until you reach 180 degrees.

But a phone is also likely going to experience bending in both directions, which can lead to metal fatigue, as well as twisting and bending at the same time.

I'm considering extending the house for toys.
A garage, to be precise - my car is first and foremost a toy.

In general, if you gain access to machines like this you are already on the network, which makes the first point less valuable.
And to be useful as a bot, you have to be able to reach somewhere from it. Being able to reach a dozen PCs on a subnet isn't too useful.

You can go behind the building the server is in and dig up and steal the flowers too. But the risk and value is too low to worry much about that. Would they be safer if we planted prickly hedges around them? Surely.

There's nothing magical about servers. They're not worth more than what's on them and what they can reach.

The above is misinformation. The cgi handler sets environment variables based on user input, which the cgi programs inherit. If and only if the cgi programs or children of the cgi programs execute bash can the exploit happen.
Either a system() call or having bash as the interpreter means you're vulnerable. But not all cgi programs are. This cgi won't trigger the bash bug:

#!/bin/tail -n+2
Content-type: application/x-msdos-program
Connection: close

X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

But in real life, we also are better at spotting when locks don't serve a purpose. Most of us don't have double bolt locks on our bathroom doors, and businesses don't keep their doors lock and run out to unlock it for every customer.

Sometimes it's not the door that needs protection, but the valuables themselves.

Keep in mind that the program that calls system() does not have to be the one that accepts environment variables from tainted input. It may inherit the environment variables from a caller who does, or it may be several layers deep.
Unless a process discards all environment variables or verifies every single set environment variable whether used or not, it may pass the problem on to another process that calls system().

It certainly works/worked on all systems I have tried it on. Did you point your GET at a cgi (or an URL aliased to a cgi) that either uses bash as an interpreter, or calls system() on a system where /bin/sh is symlinked to bash?

Also, I chose to use Cookie: as the vector for the example. Other vectors include the User-Agent: and Referer: headers. Some systems handle one but not the others - a good attack (as opposed to an example) would use all of them.

It uses /bin/sh, which is hardcoded.
Else, it would fail to execute a binary if the path was empty.

From the man page, system(3):

              The system() library function uses fork(2) to create a child process
              that executes the shell command specified in command using execl(3) as
              follows:

                      execl("/bin/sh", "sh". "-c", command, (char *) 0);

              system() returns after the command has been completed.
              The system() library function uses fork(2) to create a child process
              that executes the shell command specified in command using execl(3) as
              follows:

                      execl("/bin/sh", "sh". "-c", command, (char *) 0);

              system() returns after the command has been completed.

Um, apache and lighttpd both do. Combined, that covers most web servers.

HTTP_COOKIE gets set to the value of the Cooke: header.
Other environment variables set by the remote user include Referer: (HTTP_REFERER) and User-Agent; (HTTP_USERAGENT).

system() will generally use a hardcoded /bin/sh for its environment, no matter what your path is. Else system() wouldn't work if the path was empty.

No, it's worse than that. You don't have to pass any arguments, and you don't even have to knowingly call shell - calling system() from a language that executes binaries in a shell context will do it, on systems that have /bin/sh point to bash (which is most of them these days).

In short, anything that inherits environment variables (like TERM, LANG, LC_COLLATE) and executes anything in a shell context is vulnerable. No passing of arguments or deliberate call of bash is needed.

Fixing might not be as easy as you think. A system may run an older OS, or be an embedded system. How do you replace bash on your router or access point today?

Delete all cgis that either call batch or system(), as well as all dhcp clients? Then remove AcceptEnv variables from sshd configurations, and any other ways to pass an environment variable (including ones like LANG and TERM)?

You sure haven't understood the nature of this beast. It's MUCH worse than heartbleed, and oh so simple to exploit too.

You misunderstand the nature of the bug. Your cgi or app doesn't have to pass anything to an executable. A static call is just as vulnerable here - if a cgi app calls system("/path/to/safe/executable") with no parameters at all, you'll still be bitten, because the system() call executes /bin/sh to run the command in, and inherits the environment from the web browser.

Something like this will suffice:

telnet HOST 80 (or openssl s_client -connect HOST:443)
GET /someapp HTTP/1.1
Host: HOST
Cookie: () { :; }; /bin/cat /dev/urandom >/tmp/foo
Connection: close

... or any other command you want to execute, like perhaps an ssh out with a tunnel back in.

And it's not restricted to http cgi either. Several dhcp clients call sh, so you can get instahacked by trying to acquire an open network connection. Rather worse, because dhcpd/dhclient tend to run as root so they can set up routing and set up the resolver.
There are many other attack vectors for this one.

Yes, it's bad.

Which one of my machines? And which interface?
Here's one:
172.17.24.4
fda7:60b8:3ce4:1:0:14da:e996:ffc2
172.17.25.4
fda7:60b8:3ce4:2:0:14da:e996:ffc3

Feel better now?

But anyhow, I probably should have written "... reboots are years between, or in scheduled windows."

And that said, not all machines are reachable by hackers, or useful to them. Some I have are on their own network, with no physical connection to other networks. Others are behind several layers of firewalls and have no security anyhow.

You don't put heavy duty security locks on your bathroom door, do you?

And if that wasn't enough, there are many kernel security fixes that do not apply, so a reboot isn't needed. If a server isn't running ext4, chances are that it doesn't need to be rebooted after a fix to the ext4 code. And if the fix is to a module, reinserting the new module will generally suffice.
I actually read the release notes for security fixes.

That you don't think was assumed, but thank you for confirming the suspicion.

Yes, I have tried systemd. I try it every day. And it still cannot do what I need the system to do, especially with its own embedded udev which prevents existing applications from working, but also because it's pure hell to configure/reconfigure, especially in an automated fashion due to the MSDOS INI files and what should be an init process overriding the superuser.
No, the mail server does not need to be shut down if I shut down the locking daemon due to replacing another server that the mail daemon doesn't even talk to. And I may want multiple servers with the same configuration but with different services started, so they can be ready for a manual switch of services. And much else that is easy with systemd or upstart, but a huge amount of work with systemd. I want to be able to do things without jumping through hoops.