71–80 of 254 posts
Earlier quoted context omitted.
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.
[deleted]
Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
Glancing over the patch, this appears to be the crucial part: size_needed = (sizeof (*host_addr) - + sizeof (*h_addr_ptrs) + strlen (name) + 1); + + sizeof (*h_addr_ptrs) + + sizeof (*h_alias_ptr) + strlen (name) + 1); Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly?
It is nice if they can count. However instead of sending them back to kindergarten, it might make sense to find a compiler/language/framework that would make inability to count not result in easy remote exploits.
Here is the full Qualys report with an in-depth analysis: http://www.openwall.com/lists/oss-security/2015/01/27/9 Also contains a writeup about a remote Exim exploit (which is the default mail server on at least Debian).
From this, the vulnerability was fixed in May 2013 so any systems from there or later (e.g. Ubuntu 14.04) are fine. Older systems obviously now need to wait for the patches to come through.
[1] I wouldn't.
Glancing over the patch, this appears to be the crucial part: size_needed = (sizeof (*host_addr) - + sizeof (*h_addr_ptrs) + strlen (name) + 1); + + sizeof (*h_addr_ptrs) + + sizeof (*h_alias_ptr) + strlen (name) + 1); Doesn't it seem disappointing that some programmers, for whatever reason, just can't seem to count correctly?
It is nice if they can count. However instead of sending them back to kindergarten, it might make sense to find a compiler/language/framework that would make inability to count not result in easy remote exploits.
It's version 2.13-38+deb7u7
A standard update command should get it, but if not you can find it here:
Earlier quoted context omitted.
I'm not fully though my morning bootup process and so not really ready to grok this but, can anyone give a quick summary of why gethostbyname() needs to hit the heap at all, let alone with a realloc call? There's a maximum hostname length, and it's not huge. Also: isn't this function just saying "yes" or "no" to a candidate hostname? Can't it just say "no" if the hostname is super long?
From the GNU coding standards: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically.
the entire hostname (including the delimiting dots but not a trailing dot) has a maximum of 253 ASCII characters
In general that is a good guideline, but when the standard (RFC1035) says there is an absolute limit, there is little value in going above that as it is likely that other systems won't be able to handle it. The added complexity of dynamic allocation is also an opportunity for bugs, like this one.
https://gist.github.com/koelling/ef9b2b9d0be6d6dbab63
To test your system, simply run this (but obviously only after making sure gistfile1.c is clean ;))
wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
gcc gistfile1.c -o CVE-2015-0235
./CVE-2015-0235Earlier quoted context omitted.
From the GNU coding standards: > Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically.
http://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_... the entire hostname (including the delimiting dots but not a trailing dot) has a maximum of 253 ASCII characters In general that is a good guideline, but when the standard (RFC1035) says there is an absolute limit, there is little value in going above that as it is likely that other systems won't be able to handle it. The added complexity of dynamic allo…
Again, this is especially silly if (as it appears to first glance) the bug is in a hostname validation function, and so flexible allocation could only ever be useful in the case of a hostname that must fail validation anyways.
Dumb question perhaps, but is there a command line command I can run to test before and after that this patch has been applied successfully?
Also, you can check your glibc version with this tiny code:
#include
#include
int main (void) { puts (gnu_get_libc_version ()); return 0; }
= 2.18 is safe.
ldd --version might also do the trick.