In my understanding it means that if the application compiled against the vulnerable glibc does a gethostbyname() call it can be owned. Now since a miner typically resolves the IP of the pool it wants to connect to, the miner might be pretty easy to attack as you can relatively easy predict that it will resolve its pool sooner or later. It is unclear to my understanding if the DNS server your miner uses would discard an actual malformed answer that would trigger the vulnerability.
The firewall you have in front of your miners doesn't help anything here (except you have it locked down so much, that the miner only can connect to the pools ip and port, else the attacker just launches a reverse shell with nc or whatever is en vogue right now.
So theoretically you could just remove any DNS servers from your Pi (echo "" > /etc/resolv.conf) and instead of the name of your pool, add the IP of the pool in the web frontend (and hope your pool doesn't switch providers or whatever could make a change of IP necessary).
Other than that running "apt-get update; apt-get upgrade" and waiting for a new miner binary to be released there is not much we Terminator operators can do right now. Let's hope this will be before real exploits are being published. AFAIK there are currently only 2 PoC exploits in the wild which make it unlikely that the the average Terminator out there is targeted but that might change quickly once there is for example a module for metasploit.
True I can see that, for some reason I had not though about send a download and run type thing.
I was looking, I see the vulnerability for glibc but not really for eglibc, guess going to have to make a test bench somehow