News for hackers. Stuff that matters.

A comment on CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow.

Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by WestCoastJustin on Tuesday January 27, 2015 @11:14AM (#8953835)
When the patches are available, you need to update, and likely reboot. Mattias Geniar talks about using the following command to find processes depending on libc, any of which could be running the vulnerable code, these are core processes that you probably cannot just cycle without a reboot [1]. For me the listing looks something like this: agetty, auditd, dbus-daem, dhclient, init, master, mysqld, rsyslogd, sshd, udevd, xinetd. Many of these deal with hostnames, so I would want to be sure everything is clean, and the best option is likely a reboot.

  lsof | grep libc | awk '{print $1}' | sort | uniq
[1] http://ma.ttias.be/critical-glibc-update-cve-2015-0235-getho...
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by peterwwillis on Tuesday January 27, 2015 @11:34AM (#8953992)
They're only attacking host-lookup, so you just have to worry about people who can connect to your service and are able to control name server response. This means your network services that are internet-accessible. Everything else can wait for a maintenance window for the reboot.

  ~# netstat -lnp | grep -e "\(tcp.*LISTEN\|udp\)" | cut -d / -f 2- | sort -u
  cupsd          
  dnsmasq        
  httpd          
  nmbd           
  ntpd           
  qemu-kvm       
  rpc.portmap    
  rpc.statd      
  sendmail: acce 
  smbd           
  ssh           
  sshd
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by jerematasno on Tuesday January 27, 2015 @08:34PM (#8957488)
It doesn't have to be internet accessible, AFAIK. If an attacker can get something to do arbitrary DNS lookups, I think it can be attacked. For instance, monitoring/log correlation software might be vulnerable.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by NickNameNick on Tuesday January 27, 2015 @10:57PM (#8958001)
If you have backend systems parsing XML, then an XXE[1] attack could trigger a DNS lookup, for example.

[1]https://www.owasp.org/index.php/XML_External_Entity_%28XXE%2...

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by sarciszewski on Friday January 30, 2015 @12:50PM (#8973222)
Ooh, that could lead to some very interesting attack vectors. :D
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by correxion on Tuesday January 27, 2015 @04:17PM (#8955981)
sudo netstat -lnp | awk -F/ '/LISTEN /{print $2}'
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by contingencies on Tuesday January 27, 2015 @11:19AM (#8953874)
For immediate actions, maybe also set 'UseDNS no' in /etc/ssh/sshd_config and restart any public-facing ssh servers.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by beagle3 on Tuesday January 27, 2015 @09:34PM (#8957675)
This is a good idea in general. However, every version of ssh that I could test (going back to Ubuntu 8.04) uses getaddrinfo() rather than gethostbyname() and is therefore safe.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by beagle3 on Tuesday January 27, 2015 @11:51PM (#8958186)
... or not necessarily safe, as people here claim that getaddrinfo() uses gethostbyname() under the covers.

"UseDNS no" in your sshd_config is a good idea in general.

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by stplsd on Tuesday January 27, 2015 @01:41PM (#8954828)
Just remember that by default lsof prints only first 9 characters of process name, so processes with long names will be cut. You can change how much initial characters lsof prints with +c command, but often kernel does not supply full names for lsof, example limit in my box is 15 characters

>lsof +c 64

lsof: +c 64 > what system provides (15)

So

lsof +c 15 is maximum

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by voltagex_ on Tuesday January 27, 2015 @05:57PM (#8956736)
That limit is set somewhere in the kernel but it's not clear if lsof is just setting that as a maximum internally or probing somewhere - I used strace -etrace='!close' lsof +c 64 but I couldn't see anything related to the limit.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by michaelx386 on Tuesday January 27, 2015 @11:23AM (#8953900)
Thank you, it's not always clear when a reboot is needed after an update. I do it with kernel updates but wouldn't have in this case until I read your comment and ran the command to check.

If would be nice if package managers would let us know when this is necessary, I expect that might be a hard thing to get right though.

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by JshWright on Tuesday January 27, 2015 @11:26AM (#8953926)
You can check to see if any running process are using any stale libraries pretty easily:

sudo lsof | grep lib | grep DEL

You can then either reload those processes manually, or just bounce the box if that's easier.

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by gtrubetskoy on Tuesday January 27, 2015 @12:38PM (#8954438)
There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by JshWright on Tuesday January 27, 2015 @12:45PM (#8954475)
Yeah, that's a good point, and definitely worth mentioning, but obviously rebooting isn't going to help in that case either. The parent was asking about how they would know if they need to reboot or not.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by aidenn0 on Tuesday January 27, 2015 @01:23PM (#8954690)
It is nearly impossible to statically link glibc.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by cnvogel on Tuesday January 27, 2015 @02:11PM (#8955023)
... with nss-modules being a major culprit, ironically... (on which gethostbyname relies greatly)...
[ Parent | on HN ]
[deleted]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by teraflop on Tuesday January 27, 2015 @12:15PM (#8954285)
You're testing what happens when you delete a file for which an open file descriptor exists. On Linux, a shared library will normally be memory-mapped but will not have a corresponding file descriptor. So lsof will show DEL, not (deleted).

I wouldn't normally nitpick about something like this, but if people follow your advice they might incorrectly think they don't need to reboot.

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by nkurz on Tuesday January 27, 2015 @12:15PM (#8954287)
You can see that the removed file gets a (deleted) in the 'NAME' column but not DEL in the 'TYPE'.

Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.

[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by danielweber on Tuesday January 27, 2015 @12:22PM (#8954336)
Use contrl-F to search, it got clipped off the right-hand side by HN's raw-mode display.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by 0x0 on Tuesday January 27, 2015 @11:35AM (#8954001)
For debian, you can use "checkrestart -v" from the "debian-goodies" package.
[ Parent | on HN ]
Re:CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow by correxion on Tuesday January 27, 2015 @04:10PM (#8955927)
lsof | awk '/libc/{print $1 | "sort -u" }' you're welcome
[ Parent | on HN ]