5 ms·

Now, just to repeat the scan with: Referer: () { :; }; sudo apt-get update && sudo apt-get install --only-upgrade bash "Why, who was that masked sysadmin? W

by gojomo 12y ago

Now, just to repeat the scan with: Referer: () { :; }; sudo apt-get update && sudo apt-get install --only-upgrade bash "Why, who was that masked sysadmin? We didn't even get the chance to thank him."

gcr 12y ago
Who would grant `sudo` privileges to `www-data` without asking for a password? That's just asking for a bad time.
- dsl 12y ago
  The same people who write CGI applications in bash?
  - agwa 12y ago
    Your CGI application does not need to be written in bash for you to be vulnerable. If at any point your non-bash CGI program (and this includes PHP, even with mod_php, since it sets the same environment variables), or one of its descendant processes, executes a bash script, you can be exploited. This is especially bad on systems where /bin/sh is /bin/bash, since /bin/sh gets invoked implicitly by system(3). So you could have a non-bash CGI program invoking a non-bash program using system(3) and you can be exploited.
    - peterhu 12y ago
      According to https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223, mod_php is not vulnerable.
      - agwa 12y ago
        You're right; thanks! I saw the HTTP_* variables in phpinfo() and assumed they'd be passed on to children through system(), but they actually aren't. In fact the only environment variables passed through look pretty innocuous.
    - dsl 12y ago
      I didn't say it required it. I simply pointed out (albeit sarcastically) that CGI scripts do get written in bash, and people often often make use of sudo within them. I've seen such a beast in production at multiple companies. The amusing up/down vote war I am watching on my karma gives me hope that at least 50% of HN got it...
- zalzane 12y ago
  you could prolly get around that if their httpd.conf has incorrect privs set, you could run a script that changes the "user to run as" to root, then set up a script that would run on next reboot to apt-get upgrade and remove the root privs config line. you'd have to wait for the server to go down or reboot however long in the future, but hey it would work.
NamTaf 12y ago
Does this qualify as white-hat or grey-hat hacking? Does the doing only good outweigh the bad of modifying someone else's system?
- Mandatum 12y ago
  Relevant helpful viruses: https://en.wikipedia.org/wiki/Welchia https://en.wikipedia.org/wiki/Welchia http://virus.wikidot.com/codered http://virus.wikidot.com/codered (CodeGreen)
- danielweber 12y ago
  It's a long-running debate in the security community, almost as big as full-vs-responsible disclosure. On the pro side, it's better than you get patched than stay vulnerable and fall into someone else's zombie list. On the anti side, you don't know what you are messing with and could break things, oh, and it's illegal and you can go to jail. On the anti-anti side, if you can't be held responsible to patch your machines, don't complain when someone else does it for you. That's the barest summary.

by gojomo 12y ago

Now, just to repeat the scan with: Referer: () { :; }; sudo apt-get update && sudo apt-get install --only-upgrade bash "Why, who was that masked sysadmin? We didn't even get the chance to thank him."

gcr 12y ago

Who would grant `sudo` privileges to `www-data` without asking for a password? That's just asking for a bad time.

dsl 12y ago
The same people who write CGI applications in bash?
- agwa 12y ago
  Your CGI application does not need to be written in bash for you to be vulnerable. If at any point your non-bash CGI program (and this includes PHP, even with mod_php, since it sets the same environment variables), or one of its descendant processes, executes a bash script, you can be exploited. This is especially bad on systems where /bin/sh is /bin/bash, since /bin/sh gets invoked implicitly by system(3). So you could have a non-bash CGI program invoking a non-bash program using system(3) and you can be exploited.
  - peterhu 12y ago
    According to https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223, mod_php is not vulnerable.
    - agwa 12y ago
      You're right; thanks! I saw the HTTP_* variables in phpinfo() and assumed they'd be passed on to children through system(), but they actually aren't. In fact the only environment variables passed through look pretty innocuous.
  - dsl 12y ago
    I didn't say it required it. I simply pointed out (albeit sarcastically) that CGI scripts do get written in bash, and people often often make use of sudo within them. I've seen such a beast in production at multiple companies. The amusing up/down vote war I am watching on my karma gives me hope that at least 50% of HN got it...
zalzane 12y ago
you could prolly get around that if their httpd.conf has incorrect privs set, you could run a script that changes the "user to run as" to root, then set up a script that would run on next reboot to apt-get upgrade and remove the root privs config line. you'd have to wait for the server to go down or reboot however long in the future, but hey it would work.

NamTaf 12y ago

Does this qualify as white-hat or grey-hat hacking? Does the doing only good outweigh the bad of modifying someone else's system?

Mandatum 12y ago
Relevant helpful viruses: https://en.wikipedia.org/wiki/Welchia https://en.wikipedia.org/wiki/Welchia http://virus.wikidot.com/codered http://virus.wikidot.com/codered (CodeGreen)
danielweber 12y ago
It's a long-running debate in the security community, almost as big as full-vs-responsible disclosure. On the pro side, it's better than you get patched than stay vulnerable and fall into someone else's zombie list. On the anti side, you don't know what you are messing with and could break things, oh, and it's illegal and you can go to jail. On the anti-anti side, if you can't be held responsible to patch your machines, don't complain when someone else does it for you. That's the barest summary.