Hacker News new | past | comments | ask | show | jobs | submit login

Unless I've missed something, could some benevolent person use the bug to cause remote systems to run something like "sudo apt-get update && sudo apt-get install bash", to patch the vulnerability automatically? (it makes lots of assumptions, but surely it's better to have some patched systems as a result.)



Certain worms include a patching step like this when they infect a machine to avoid losing control via re-infection.

For a high school science research course I did an epidemiological modeling study on how "good" reverse-worms might affect the spread of infection, they're a pretty interesting thought experiment. With something involving exponential growth like this, early movers have a significant advantage.

As far as I know, there hasn't been a successful reverse-worm that did not accidentally cause worse issues (flooding local networks with a high density set of boxes doing over-zealous scanning, or accidentally destroying boxes due to a slapdash narrowly tested script).

Reverse-worms they can either wait around, detecting requests from infected-but-not-patched systems to re-infect and patch them—or just start scanning IP ranges themselves. The former feels somewhat less pernicious. "Try to infect this computer, you will be patched and help patch." But that relies on other worms not patching their zombies.


It may be possible to exploit the bug for "good" reasons like patching the bug, but the patches that are out now don't seem to properly plug the exploit, and as with any update there are plenty of considerations that could end up bricking the application.

Aside from the "it's not yours to fix" angle, you have to weigh the moral benefits of possibly patching the exploit, possibly crashing the application (I bet this is much more likely than a successful fix at this point), and wait-and-seeing whether the application owner patches the exploit on their own (along with the risk of a compromise in the mean time).

Edit: Of course there are a slew of legal issues with attempting this as well.


"could some benevolent person use the bug to cause remote systems to run something like "

That's not benevolent that's intrusion. Nobody has the right to take it upon themselves to determine what someone else should be doing in this case. I would imagine that an action like that would also clearly violate a law or two (I'm sure others more knowledgeable could cite the law).


At the risk of participating in a philosophical debate, I pose a classic counterexample:

You encounter a car parked on the side of the road in the middle of nowhere. Its windows are rolled down. Storm clouds are rumbling nearby and it's obviously about to rain. There's nobody around but you.

Do you also consider rolling up the windows to be intrusion?

Personally I'd feel an ethical obligation to help the stranger out by preventing damage to his/her property. However I can completely understand people leaving well-enough alone.

Law aside, I'm much more on the fence about people automatically scanning for and "fixing" vulnerabilities, however. On one hand, how do you know you're really helping? On the other, as someone who's maintained a server or two, I'd rather be solving problems caused by a well-intentioned whitehat than miss problems caused by ill-intentioned blackhats.


"Do you also consider rolling up the windows to be intrusion?"

Yes definitely. Really no different than if you would want someone to enter your house to close your windows.

Now you might say "well what if it can be done from the outside" without entering?

That is a bit different.

Except for one thing. What if someone saw you doing that? What if the owner saw you doing that and didn't know why you were messing with their car? (I had this happen with a boat one time btw.). There is an immediately sense of shock because you don't know what is going on. And in that case who knows what will happen? Maybe they might start a fight or shoot you. That's not good for anyone. Maybe they have something valuable in the car that they think you are going after. Maybe they have serious mental problems.

Here's the point. It's one thing if you see a baby in a hot car and decide to take action. The benefit outweighs the risks. But it's another thing if you decide to roll up the windows to prevent someone's car from getting wet inside (covered by homeowners insurance with low deductible in many cases ntim though). Different story. Make sense?


Depends on if it has power windows ;)


Better to use:

echo You are vulnerable to shellshock | wall


sudo requires a password to be entered by default, right? I would guess that for most setups this wouldn't be possible without some kind of privilege escalation as well (or if the webserver was running with root privileges).


You'd be surprised by the number of servers that don't ask for password when you try to use sudo. They just assume that the actual owner issued the command and go straight to issuing the command as root.

(Caveat: typically it has to be a certain user)

I'm ashamed to admit I used to think that was convenient. It makes systems infinitely more vulnerable in the event of an RCE bug.


Many systems still use passwordless sudo to permit certain users to run specific commands -- but now, if those commands are shell scripts run via bash, the users can execute arbitrary commands (this isn't an uncommon class of privilege escalation problem, though).


and how would the "benign attacker" know the super user password that sudo will ask for? its not like this is a logged in ssh session.


sudo can be set up lots of different ways -- including such that there's no password needed.

> its not like this is a logged in ssh session

That's not correct -- whatever user is executing your CGI scripts is the "logged-in" user in bash, right?

Obviously that user should be quite locked down, and should not be allowed to run sudo at all, let alone without a password... but there are so many amateur server admins out there that I imagine there are quite a few servers where this is a serious problem (with or without sudo access enabled for the executing user).


Extremely good point, thank you. :)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: