5 ms·

cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amo

by r1ch 12y ago

cPanel is probably the most popular reseller hosting software for shared web hosting and it relies on CGI in all kinds of places. That alone provides a huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it seems down right now. Since cPanel is designed for people without system administration experience, it's unlikely they will be patched in a timely manner too. All the CGI scripts are in known static locations, so I wouldn't be surprised to see a worm that targets cPanel servers very soon. This is definitely not going to affect just a few legacy CGI sites.

ck2 12y ago
cPanel uses CentOS and does system upgrades ala yum update. Dunno if that is on by default or not though. But you aren't going to get into its cgi interface without login so that would have to be cracked first.
- r1ch 12y ago
  Hmm, it's been a while since I last touched cPanel (almost 10 years), but I recall it automatically included aliases for cgi scripts into each vhost. Try /cgi-sys/guestbook.cgi on any cPanel website for example (a random Google example: https://www.vidahost.com/cgi-sys/guestbook.cgi https://www.vidahost.com/cgi-sys/guestbook.cgi)
- pbhjpbhj 12y ago
  But it seems you only need one login to compromise the whole server. If I buy $3 hosting on a shared server then I can pwn the whole server can't I (using cPanel to escalate an attack above my privelege level)? What are the chances that one user account on a shared server is crackable, pretty high I'd imagine.
peterwwillis 12y ago
cPanel's official notice is that they checked and their code is not vulnerable (at least, whatever their current code is). Of course it's possible that other CGI apps will execute a shell at some point, and that there's bound to be plenty of servers that are exploitable. But the number of SSL-bearing sites, and the sheer number of users (I mean, hundreds of millions, at least) that were exposed due to such gigantic sites having a huge hole for so long, meant that virtually everyone's personal information was vulnerable, immediately, to say nothing of stealing SSL keys. This is definitely a serious bug. Any remote code execution is a top priority. But i've never seen a bug like Heartbleed before, and it's unlikely we ever will again, as (hopefully?) it will change the way forward services are deployed to implement proper memory protection between transport and application layers. Compared to exposing the personal information (and secured keys) of so many users and domains, just executing code on miscellaneous servers seems cute in comparison.

by r1ch 12y ago

ck2 12y ago

cPanel uses CentOS and does system upgrades ala yum update. Dunno if that is on by default or not though. But you aren't going to get into its cgi interface without login so that would have to be cracked first.

r1ch 12y ago
Hmm, it's been a while since I last touched cPanel (almost 10 years), but I recall it automatically included aliases for cgi scripts into each vhost. Try /cgi-sys/guestbook.cgi on any cPanel website for example (a random Google example: https://www.vidahost.com/cgi-sys/guestbook.cgi https://www.vidahost.com/cgi-sys/guestbook.cgi)
pbhjpbhj 12y ago
But it seems you only need one login to compromise the whole server. If I buy $3 hosting on a shared server then I can pwn the whole server can't I (using cPanel to escalate an attack above my privelege level)? What are the chances that one user account on a shared server is crackable, pretty high I'd imagine.

peterwwillis 12y ago

cPanel's official notice is that they checked and their code is not vulnerable (at least, whatever their current code is). Of course it's possible that other CGI apps will execute a shell at some point, and that there's bound to be plenty of servers that are exploitable. But the number of SSL-bearing sites, and the sheer number of users (I mean, hundreds of millions, at least) that were exposed due to such gigantic sites having a huge hole for so long, meant that virtually everyone's personal information was vulnerable, immediately, to say nothing of stealing SSL keys. This is definitely a serious bug. Any remote code execution is a top priority. But i've never seen a bug like Heartbleed before, and it's unlikely we ever will again, as (hopefully?) it will change the way forward services are deployed to implement proper memory protection between transport and application layers. Compared to exposing the personal information (and secured keys) of so many users and domains, just executing code on miscellaneous servers seems cute in comparison.