Comment Re:Capture it (Score 1) 54
Earths gravity is pushing it away.
So it's an antimatter quasi-moon, then?
Otherwise, Earth's gravity would be pulling it away.
Earths gravity is pushing it away.
So it's an antimatter quasi-moon, then?
Otherwise, Earth's gravity would be pulling it away.
If Ebola takes a foothold in the U.S., will it's citizens react compassionately?
No, I do not think the US population is capable of changing overnight.
file * | awk '($2 = "POSIX")' | cut -d: -f1 | xargs checkbashisms
Lesson to self: Test before posting. That should be == instead of =, of course:
file * | awk '($2 == "POSIX")' | cut -d: -f1 | xargs checkbashisms
Sorry about that.
On a Fedora / Red Hat / CentOS / ScientificLinux box, do:
yum install rpmdevtools
cd
file * | awk '($2 = "POSIX")' | cut -d: -f1 | xargs checkbashisms
Yeah, "too much" is an understatement.
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.
Any machine in a network is useful to hackers. Just because it doesn't store and sensitive data doesn't mean that I can't use it to attack the rest of your network or use it as a bot.
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.
You're a bit confused there. The exploit happens before the cgi itself is run. The simple fact of using cgi is the vulnerability here, so it should be "remove all cgis".
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*
Every lock, every door can be attacked and broken. It's no different with protocols. We don't stop locking our bikes or cars just because a government soldier with an M16 can shoot the lock open.
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.
Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.
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().
I have an unpatched test system which has the Bash flaw and I cannot get your example to work. Maybe the flaw isn't as pervasive as you claim.
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
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.
For example, what happens if you make sure
It uses
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.
That requires the interpreter to copy the value of Cookie into an environment variable, so it won't work if that is not done. Don't know what web server you are talking about that does that.
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
Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash.
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
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.
"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."
