Quote from: coinflow on March 10, 2016, 11:33:30 AM

Quote from: psycodad on February 28, 2016, 06:15:11 PM

Quote from: emdje on February 28, 2016, 05:00:23 PM

Quote from: psycodad on February 25, 2016, 05:45:53 PM

Quote from: mjgraham on February 25, 2016, 04:19:51 PM

Quote from: psycodad on February 25, 2016, 03:38:43 PM

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

eglibc is equally affected from the problem as far as I can judge:

i.e.: http://www.ubuntu.com/usn/usn-2485-1/

I am not that into coding and software as I would like. Do I read it correctly that because I have build the cgminer builds on the raspberry pi and not under Ubuntu that the builds are not vulnerable??

Most advisories only talk about glibc, but I am pretty confident all previous versions of eglibc were vulnerable (no matter if ubuntu or debian):

https://www.debian.org/security/2016/dsa-3480

If you still have your build system available, just apt-get upgrade it and then make the binary again, that should be sufficient (eventually a make clean would be advisable before).

Could you explain what make does in detail? Does it include the glib-code (or parts of it) in the output or only links to the relevant things? If it does the latter, then would it not be sufficient to only upgrade the system and the previously compiled results then would point to the upgraded, non-vulnerable version?

Good point, I am not expert enough to answer this.
To my knowlegde if eglibc has not been linked statically then this could be enough (= if -static was not used for building).