Hi
Just wondering whether the ghost vulnerability affects the SLES 11 SP 1.
Does anyone have a view on this?
Cheers, JP
Apologies, patches here
Yes, I believe it does. The fixes for SLES have already been out for a
couple of days so you can look for those if you’re current on maintenance
with something still receiving updates (SLES 11 SP3 updates were the ones
I pulled down a couple of nights ago). If you have LTSS support for an
earlier SP then those should show up as well. Alternatively, patch to a
supported version.
The Qualys report for GHOST has a sample program you can compile/run to
test if you are impacted, at least in theory. Apparently a lot of default
services are NOT impacted, so this isn’t as big as originally thought;
still, who knows if you have other services that are impacted, or if you
give local access to users who may exploit things, etc.
http://www.openwall.com/lists/oss-security/2015/01/27/9
Sample code from URL above, just for simplicity:
#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);
if (strcmp(temp.canary, CANARY) != 0) {
puts("vulnerable");
exit(EXIT_SUCCESS);
}
if (retval == ERANGE) {
puts("not vulnerable");
exit(EXIT_SUCCESS);
}
puts("should not happen");
exit(EXIT_FAILURE);
}You probably should not trust this code, since you have no idea if I’ve
mangled it to do something evil to you. Still, if you do, put it into a
‘ghost.c’ file and then compile and run it:
gcc ghost.c -o ghost
../ghostThe result is it will either tell you ‘vulnerable’ or ‘not vulnerable’.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Note that page lists an update for SLES 11 SP1 LTSS* not SLES 11 SP1. If you go to Patch Finder there’s a glibc update for SLES SP1 LTTS
https://download.suse.com/patch/finder/#bu=suse&familyId=7261&productId=45404
but not for SLES 11 SP1
https://download.suse.com/patch/finder/#bu=suse&familyId=7261&productId=26322
Hello
does this update needs servers reboot or applications restart in production enviroment ?
As you can find on https://www.novell.com/support/kb/doc.php?id=7016113 reebot/restart is not required
[QUOTE=kotek6;26104]Hello
does this update needs servers reboot or applications restart in production enviroment ?
As you can find on https://www.novell.com/support/kb/doc.php?id=7016113 reebot/restart is not required[/QUOTE]
I’m confused by your post. You ask a question only to then immedietly answer it and you answer it incorrectly. The KB article you link to says “A reboot is required when updating glibc”.
Thank you and sorry I did`t catch it.
On 02/02/2015 17:44, mikewillis wrote:
[color=blue]
I’m confused by your post. You ask a question only to then immedietly
answer it and you answer it incorrectly. The KB article you link to says
“A reboot is required when updating glibc”.[/color]
FWIW my reading of TID 7016113 is that if you “1. Update your entire
system with the latest system updates:” then “A reboot is required when
updating glibc” but if you “2. Apply only the latest glibc patches” then
you do not.
If updating your entire system with latest system updates which include
a kernel upgrade then you do need to reboot (which zypper/YaST will
report) but if just updating glibc then you can restart the various
processes referencing glibc thus avoid the restart. “zypper ps” will
report the various processes that need restarting.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
[QUOTE=smflood;26350]On 02/02/2015 17:44, mikewillis wrote:
[color=blue]
I’m confused by your post. You ask a question only to then immedietly
answer it and you answer it incorrectly. The KB article you link to says
“A reboot is required when updating glibc”.[/color]
FWIW my reading of TID 7016113 is that if you “1. Update your entire
system with the latest system updates:” then “A reboot is required when
updating glibc” but if you “2. Apply only the latest glibc patches” then
you do not.
If updating your entire system with latest system updates which include
a kernel upgrade then you do need to reboot (which zypper/YaST will
report) but if just updating glibc then you can restart the various
processes referencing glibc thus avoid the restart. “zypper ps” will
report the various processes that need restarting.
[/QUOTE]
Huh. Yeah, I can see that interpretation because “2. Apply only the latest glibc patches” doesn’t say anything about a reboot. But section 1 contains
I think it would read better as one sentence ( updating glibc in order for ), but it does provide an explanation for why a reboot is required after updating gblic.
Perhaps use of the ‘Provide Feedback’ link on the TID is merited.
On 12/02/2015 15:44, mikewillis wrote:
[color=blue]
Huh. Yeah, I can see that interpretation because “2. Apply only the
latest glibc patches” doesn’t say anything about a reboot. But section 1
contains[color=green]Note: A reboot is required when updating glibc. In order for the patch
to address the gethostbyname*() vulnerability listed for this CVE.[/color]
I think it would read better as one sentence (�updating glibc in order
for�), but it does provide an explanation for why a reboot is required
after updating gblic.[/color]
Well if you install a kernel update zypper will prompt that the machine
needs restarting but you don’t get such a message when just updating glibc.
[color=blue]
Perhaps use of the ‘Provide Feedback’ link on the TID is merited.[/color]
That I may do when I get a moment.
HTH.
Simon
SUSE Knowledge Partner