Ghost - what does it mean for ZK?

Only if you could force a hostname resolution with arbitrary input (and a host of other requirements, see below). That's why an email server is the ideal target for this attack. ZK probably dodged this one by not dealing with emails at all. I can't think of anywhere else untrusted domains would be resolved.

EDIT:

Reading a bit more of the technical details, you only get sizeof(char*) bytes (4 or 8). So all you can really do is (hopefully) clobber a return address if you're lucky enough to have the buffer on the stack. The vast majority of programs will use non re-entrant gethostbyname, which means you're looking at a heap overflow instead. In this case you're praying to blow away a function pointer with the address of some other function that does which you want (you'll need to have the address of your target handy). Also, any pre-resolution hostname validation will catch exploit attempts. Add on to that the fact that only [0-9.] and \0 can be used in the payload, and this attack really becomes esoteric and impractical outside of a lab. In order to reliably exploit this you'd need to have knowledge or control of so many factors that you either already pwned the server or have more feasible attack vectors.

All in all, probably nothing to see here.

EDIT Again:
nmap thinks zero-k.info is running on a windows server. not sure if that runs the other junk too.

quote: Read a bit more. Those few bytes can be enough for full-fledged attacks.

The only "full-fledged" attack they detailed with ACE was the exim vuln, in which they noted:

quote: The success of this exploit depends on an important piece of information: the address of Exim's run-time configuration in the heap.

Which, with ASLR, is extremely difficult to know ahead of time. In this case, they were able to exploit another exim-specific flaw to get the address they needed (outlined in 5.2). This entire scheme depends on the gethostbyname buffer being directly adjacent to a malloc chunk, and also that heap protection was not enabled.

Finally, further down the thread is a list of programs that are accidentally unexploitable despite calling the affected functions: http://www.openwall.com/lists/oss-security/2015/01/27/18

Which speaks to the "perfect storm" required to exploit this in the wild against an uncompromised machine.

Do u want to ask that for every security issue what is found? Thing is that this bug is only in the news because such bugs are rare for Linux.
Imagine everyone would start to post windows security bugs?