CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow

Post by kyboren » Tue, Jan 27, 2015, 10:26 PM UTC

amlweems wrote: post #35

Qualys Security Advisory: http://www.openwall.com/lists/oss-security/2015/01/27/9 Lots of info about their discovery. Apparently they developed a PoC exploit. They've also included a pretty short test program to determine if a system is vulnerable or not. Here's a gist of the test (copied from their advisory): https://gist.github.com/amlweems/6e78d03810548b4867d6

    - At most sizeof(char *) bytes can be overwritten (ie, 4 bytes on 32-bit
      machines, and 8 bytes on 64-bit machines). Bytes can be overwritten
      only with digits ('0'...'9'), dots ('.'), and a terminating null
      character ('\0').

    - Despite these limitations, arbitrary code execution can be achieved.
      As a proof of concept, we developed a full-fledged remote exploit
      against the Exim mail server, bypassing all existing protections
      (ASLR, PIE, and NX) on both 32-bit and 64-bit machines. We will
      publish our exploit as a Metasploit module in the near future.

Post by voltagex_ » Tue, Jan 27, 2015, 10:28 PM UTC

DangerousPie wrote: post #77

Here is the test program, from http://www.openwall.com/lists/oss-security/2015/01/27/9 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-0235

Post by Xylakant » Tue, Jan 27, 2015, 10:34 PM UTC

acveilleux wrote: post #176

Xylakant wrote: post #169

Earlier quoted context omitted.

There's no pipe involved in the GPs posting. It downloads a source file and the post even points out to check the file before compiling. I actually copied and pasted the test code from the original advisory. Should I have typed it in with my own bare fingers to be more secure? I agree with your sentiment in general, you just picked the wrong example to bash here.

The average Linux IT guy will not read the C code. Many of them wouldn't be able to really understand what it does either. And this is best case code is simple and easy to grok.

Post by zxcdw » Tue, Jan 27, 2015, 10:48 PM UTC

lazaroclapp wrote: post #170

mackal wrote: post #161

Earlier quoted context omitted.

I hate these "just use another language! All problems solved" kind of posts. Mainly because it's shit logic.

Except, "just use another language! All problems of this huge category solved!" is true in this case. You can't have buffer overflows on a memory-safe language. Sure, this is only true assuming the VM and all the stuff it depends on is formally verified not to have buffer overflows either, which is unlikely to happen. But even so, you get the slightly weaker guarantee: "just use another language! All problems of this…

Post by voltagex_ » Tue, Jan 27, 2015, 10:57 PM UTC

stplsd wrote: post #123

WestCoastJustin wrote: post #14

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, ud…

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