Forgot your password?
typodupeerror

Comment: Re:Useless (Score 1) 302

by arth1 (#48010283) Attached to: Consumer Reports: New iPhones Not As Bendy As Believed

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.

Comment: Re:kill -1 (Score 1) 469

by arth1 (#48008673) Attached to: Fork of Systemd Leads To Lightweight Uselessd

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.

Comment: Re:Worse than Heartbleed? (Score 1) 317

by arth1 (#48008625) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

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*

Comment: Re:locks, doors, ... (Score 1) 185

by arth1 (#48004015) Attached to: Security Collapse In the HTTPS Market

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.

Comment: Re:"could be worse than Heartbleed" (Score 2) 317

by arth1 (#48002981) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

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().

Comment: Re:It's been in bash a while. (Score 1) 317

by arth1 (#48001547) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

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 /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.

Comment: Re:"could be worse than Heartbleed" (Score 1) 317

by arth1 (#47999775) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

For example, what happens if you make sure /bin/sh is a good patched bash, or it's dash instead, but then /usr/local/bin shows up first in PATH and contains an old crusty version of bash and sh, which one does system() use?

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.

Comment: Re:It's been in bash a while. (Score 1) 317

by arth1 (#47999739) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

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).

Comment: Re:"could be worse than Heartbleed" (Score 4, Informative) 317

by arth1 (#47997661) Attached to: Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

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 /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.

The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford

Working...