search

gearman / gearmand

http://gearman.org/
Other
740 stars 137 forks source link

Issue #304: Fix IPv6 addresses in gearadmin --workers and log output #333

Closed esabol closed 2 years ago

esabol commented 2 years ago

Credit for this goes to Andy B (Launchpad Id: u-launchpad-x) who submitted this patch to the gearmand Launchpad on 2014-05-14. The original Launchpad URL for this patch is https://bugs.launchpad.net/gearmand/+bug/1319250.

Andy B wrote:

Steps to reproduce:

  1. start gearmand
  2. on ipv6 localhost: gearadmin -h ::1 --workers
  3. on ipv6 link-local: gearadmin -h fe80::a00:27ff:fe34:3379%eth0 --workers

Actual output for 2: 33 ::e8bf:8995:757f:0%33 - : . Actual output for 3: 33 fe80::e8bf:444b:657f:0%33 - : .

Expected output for 2: 33 ::1 - : . Expected output for 3: 33 fe80::a00:27ff:fe34:3379%eth0 - : .

This is due to struct sockaddr not being big enough to hold struct sockaddr_in6. struct sockaddr_storage is supposed to be used for this. Attached patch fixes this.

I did not observe a crash from this, but it appears that data beyond the end of the structure is being accessed (I've observed the ipv6 scope identifier being the same value as the worker offset, 33 and %33 as shown above, in every case during my research), which may be exploitable to cause a DOS.

I did modify Andy B's patch slightly to also address the !HAVE_ACCEPT4 case. There's no reason I'm aware of to not also use sockaddr_storage with accept(). There are plenty of examples all over the Internet doing so. I think that was just an oversight or perhaps an assumption that any system without accept4() wouldn't also support IPv6.

SpamapS commented 2 years ago

I for one welcome our new ipv6 overlords.