But it gets better than tunneling over ICMP: DNS tunneling. Pretty much all systems can talk to a DNS resolver. If it resolves arbitrary host names, you can set up a DNS for a zone you control and requests will end up there. With tools like iodine (requires root and a binary on the target), you can tunnel your traffic conveniently (and slowly).
It's only a dozen kbytes/sec or so, but this is more than good enough for RSS, email, IRC, HN, ...
It's not a terrible idea, but it's pretty far down the list if things to do. It will stop mass scanners, but probably not any targeted attack unless you try REALLY hard (and then you have a chance of breaking your own infrastructure by accident doing this).
They should start with updating their ghostscript sometime over the last 10 years. Then maybe think about separating some parts of their infrastructure.
I mean, wow, that's really 2012 tech, looks like new owner d invested completely nothing since acquiring 4chan.
Also "reverse tunnel" as a more general term, it can open any service not just those giving shell access. There have been similar hacks where the implanted tunnel have access to databases that weren't properly secured (anyone remember back when SQL Server defaulted to having a blank password for "sa" and many didn't change that thinking their firewall, which was really little more than a simple NAT setup, was sufficient protection?).
This is why there is the mantra "NAT is not a firewall": if something internal has no business making outgoing connections it should be blocked as well as incoming connections being difficult (also because there are various other NAT busting attacks too).
It takes the normal client/server architecture and turns it inside out. If you remember FTP and active vs passive, it works like active mode FTP.
That's just one way to do it. If the attacker wants to actually listen on an open port on a compromised server that's behind a firewall, look up 'NAT traversal' for like half a dozen ways to do it.
One interesting method to get a shell that I read about is (ab)using ICMP echo requests. ICMP echo requests can contain arbitrary bytes as a payload. So the exploit will poll the attacker's IP address with ICMP echo requests. The exploit will have data payloads that have the shell's output. The attacker's server will respond with ICMP echo requests that have whatever the attacker wants to type into the shell. It's kinda janky but it works. Lots of firewalls might block outbound UDP/TCP connections from internal servers that don't need to make outbound connections, or might whitelist the addresses they're allowed to connect to. But they won't block ICMP, either because it's considered harmless or they forgot or they didn't know it needs to be blocked separately with other rules.
The point is there's any number of ways to do it, each more clever than the last.