4 ms·

I run a server on OVH, but I figured as I don't run any dynamic web app on it, I was unaffected by shellshock - the only way in is through the web server (which

by sspiff 12y ago

I run a server on OVH, but I figured as I don't run any dynamic web app on it, I was unaffected by shellshock - the only way in is through the web server (which basically hosts a bunch of static files), or SSH. From what I understood, shellshock was caused by poor sanitation of bash variable extension, and so only posed a threat to people who used bash from their public-facing interfaces, hosted bash CGI scripts, ... Was I wrong to assume that I was safe?

SCHiM 12y ago
Yes. I've seen attempts to exploit bash via http headers (the headers them selves). Like so: GET / HTTP/1.1\r\n Host: () { :;}; echo vulnerable\r\n User-Agent: () () { :;}; echo vulnerable\r\n\r\n So even static servers could have been vulnerable. I'm not sure if your server was vulnerable or not, but I think you were definitely too soon with assuming you were safe.
- tokenizerrr 12y ago
  This exploit only works if bash is called at all during the handling of the request. This is typically only the case with CGI scripts, or when the requested application does a system() call or directly calls out to bash
  - SCHiM 12y ago
    Though it should certainly not happen, it's not uncommon for various applications to 'shell-out' certain tasks. The point I was trying to make is that you're not necessarily secure just because you don't use CGI or only host static content, and that exploitation via the web server could certainly have been possible.
TazeTSchnitzel 12y ago
Any time any user data is stored in an environment variable and bash is called somewhere down the line, you've got a problem. This means any CGI script is affected if bash is the default shell, for example.
pdkl95 12y ago
The big problem with shellshock is that the attack surface is found pretty much everywhere. The HTTP server attacks using the CGI environment (HTTP_USER_AGENT, etc) was only the most obvious way to exploit the bug. There is no way to predict all the ways a vulnerable bash could be exploited; we are going to see these attack for decades. Old firmware and poorly-maintained servers are just waiting for someone to find some clever trick that lets an environment variable be set remotely. I would guess that we haven't even begun to see the subtle ways shellshock can be exploited. So yes, patch everything, or you are taking a bet that there will not be any sufficiently clever attackers in the entire future lifetime the server.
stevekemp 12y ago
Hard to say, without knowing what you are running. I've seen people try to exploit this by email, hoping that users have ".forward" or ".procmail" files which are processed with bash, or which use it to execute commands, for example.
spindritf 12y ago
You're probably fine but update anyway and be sure.

by sspiff 12y ago

SCHiM 12y ago

Yes. I've seen attempts to exploit bash via http headers (the headers them selves). Like so: GET / HTTP/1.1\r\n Host: () { :;}; echo vulnerable\r\n User-Agent: () () { :;}; echo vulnerable\r\n\r\n So even static servers could have been vulnerable. I'm not sure if your server was vulnerable or not, but I think you were definitely too soon with assuming you were safe.

tokenizerrr 12y ago
This exploit only works if bash is called at all during the handling of the request. This is typically only the case with CGI scripts, or when the requested application does a system() call or directly calls out to bash
- SCHiM 12y ago
  Though it should certainly not happen, it's not uncommon for various applications to 'shell-out' certain tasks. The point I was trying to make is that you're not necessarily secure just because you don't use CGI or only host static content, and that exploitation via the web server could certainly have been possible.

TazeTSchnitzel 12y ago

Any time any user data is stored in an environment variable and bash is called somewhere down the line, you've got a problem. This means any CGI script is affected if bash is the default shell, for example.

pdkl95 12y ago

The big problem with shellshock is that the attack surface is found pretty much everywhere. The HTTP server attacks using the CGI environment (HTTP_USER_AGENT, etc) was only the most obvious way to exploit the bug. There is no way to predict all the ways a vulnerable bash could be exploited; we are going to see these attack for decades. Old firmware and poorly-maintained servers are just waiting for someone to find some clever trick that lets an environment variable be set remotely. I would guess that we haven't even begun to see the subtle ways shellshock can be exploited. So yes, patch everything, or you are taking a bet that there will not be any sufficiently clever attackers in the entire future lifetime the server.

stevekemp 12y ago

Hard to say, without knowing what you are running. I've seen people try to exploit this by email, hoping that users have ".forward" or ".procmail" files which are processed with bash, or which use it to execute commands, for example.

spindritf 12y ago

You're probably fine but update anyway and be sure.