- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page