Software Archive
Read-only legacy content
17061 Discussions

MPSS 3.4.3 Glibc error: gethostbyname_r returns EINVAL not ERANGE

Peter_H_Intel
Employee
763 Views

 

The following is a slightly modified test for the GHOST vulnerability:

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  printf("temp.canary = %s\n", temp.canary);
  printf("CANARY = %s\n", CANARY);
  int myret;
  myret = strcmp(temp.canary, CANARY);
  printf("strcmp return value = %d\n", myret);
  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  printf("ERANGE = %d\n", ERANGE);
  printf("EINVAL = %d\n", EINVAL);
  printf("retval = %d\n", retval);
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

 

 

When compiled with "icc (ICC) 15.0.2 20150121" on my linux host with updated glibc that has the patch for the Ghost vulnerability, I get: 

[root@compute-0-0 ~]# ./a.out 
temp.canary = in_the_coal_mine
CANARY = in_the_coal_mine
strcmp return value = 0
ERANGE = 34
EINVAL = 22
retval = 34
not vulnerable

 

Which is what I expect.

When I compile it with icc -mmic and run it on the card, I get:

[root@compute-0-0-mic0 ~]# ./ghost.k1om 
temp.canary = in_the_coal_mine
CANARY = in_the_coal_mine
strcmp return value = 0
ERANGE = 34
EINVAL = 22
retval = 22
should not happen

Which is incorrect.

 

A quick Google search gives me:

https://sourceware.org/bugzilla/show_bug.cgi?id=15014

It looks like an updated GlibC will be needed to fix this bug. 

Peter Hartman

peter.hartman@intel.com

 

0 Kudos
5 Replies
Kevin_D_Intel
Employee
763 Views

Thank you for reporting this Peter. The fix will need to come via an MPSS release and not icc. I submitted this (via Premier #6000088337) to the appropriate support team and will keep you updated on the progress of a fix in a future release. I will update the internal tracking id below once that's been assigned.

(Internal tracking id: HSD# - 5162405)

(Resolution Update on 04/28/2015): This defect is fixed in the Intel® MPSS 3.4.4 release (or later).

0 Kudos
Evan_P_Intel
Employee
763 Views

I asked around about this and, according to one of the MPSS team's security engineers, the GHOST vulnerability has in fact already been fixed in MPSS 3.4.3, as well as in the most recent point-release of certain earlier versions. However, the engineer that backported the patch onto MPSS' version of glibc was extremely conservative, and chose to carefully preserve the existing EINVAL error return. This approach caused some internal consternation (since it would necessarily lead third parties, like yourself, to believe GHOST had not been patched), so the code has since been reworked again to return ERANGE. The slight delay from this additional rework coupled with the order in which fixed versions of releases were published has, somewhat perversely, resulted in the most recent release, 3.4.3, having only the first of the two changes, while some (all?) of the point-releases made for older versions have both.

According to this engineer, it's relatively easy to verify that the vulnerability has been patched, despite the alarming error return, by instruction-stepping through gethostbyname_r with GDB.

3.4.4 should resolve this confusing situation.

0 Kudos
Peter_H_Intel
Employee
763 Views

Thanks, this sounds good to me. I'm going to put a version of this note in my release notes, and I will update to 3.4.4 when it comes out.

 

Peter

0 Kudos
Kevin_D_Intel
Employee
763 Views

I wanted to pass on that the MPSS Support team notified me that the complete set of changes Evan indicated will be in the forthcoming MPSS 3.4.4 release are already available in the recently announced MPSS 3.5 release, just in case wanted to upgrade to MPSS 3.5.

0 Kudos
pbkenned1
Employee
763 Views

This is fixed in MPSS 3.4.4 or later (per HSD 5162405, in all 3.5 and 3.6 branches), so I am closing this ticket now. 

Patrick (covering for Kevin)

C:\Users\pbkenned\ISN\U542580>icl -Qmic u542580.c
Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.3.208 Build 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

C:\Users\pbkenned\ISN\U542580>"C:\Program Files\Intel\MPSS\bin\micnativeloadex.exe" a.out
temp.canary = in_the_coal_mine
CANARY = in_the_coal_mine
strcmp return value = 0
ERANGE = 34
EINVAL = 22
retval = 34
not vulnerable


C:\Users\pbkenned\ISN\U542580>micinfo
MicInfo Utility Log
Created Tue Apr 28 08:41:46 2015


        System Info
                HOST OS                 : Windows
                OS Version              : Microsoft Windows Server 2008 R2 Enterprise
                Driver Version          : 3.5.37182.0
                MPSS Version            : 3.5.37182.0

0 Kudos
Reply