The GHOST vulnerability [CVE-2015-0235] can be exploited on Linux systems that use versions of the GNU C Library prior to glibc-2.18. Systems that use an unpatched version of glibc from versions 2.2 to 2.17 are at risk.

Its a buffer overflow bug affecting the gethostbyname() and gethostbyname2() function calls. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.

Check System Vulnerability

To test if your servers are vulnerable to GHOST, check the version of glibc that is in use.

Ubuntu & Debian

To check the version of glibc run the following command:

ldd --version

The first line of the output will contain the version of eglibc, the variant of glibc that Ubuntu and Debian use. for example:

ldd (Ubuntu EGLIBC 2.15-0ubuntu10.10) 2.15
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

If the version of eglibc matches, or is more recent than the ones listed here, you are safe from the GHOST vulnerability:

  • Ubuntu 12.04 LTS: 2.15-0ubuntu10.10
  • Ubuntu 10.04 LTS: 2.11.1-0ubuntu7.20
  • Debian 7 LTS: 2.13-38+deb7u7

If the version of eglibc is older than the ones listed here, your system is vulnerable to GHOST and should be updated.

Continue reading

On September 24, 2014, a GNU Bash vulnerability, referred to as Shellshock or the “Bash Bug”, was disclosed. In short, the vulnerability allows remote attackers to execute arbitrary code given certain conditions. Because of Bash’s ubiquitous status amongst Linux, BSD, and Mac OS X distributions, many computers are vulnerable to Shellshock; all unpatched Bash versions between 1.14 through 4.3 (i.e. all releases until now) are at risk.

A detailed description of the bug can be found at CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, and CVE-2014-7187.

Check System Vulnerability

You may check for the Shellshock vulnerability by running the following command at the bash prompt:

env 'VAR=() { :;}; echo Bash is vulnerable!' 'FUNCTION()=() { :;}; echo Bash is vulnerable!' bash -c "echo Bash Test"

The code echo Bash is vulnerable! portion of the command represents where a remote attacker could inject malicious code. Therefore, if you see the following output, your version of Bash is vulnerable and should be updated:

Bash is vulnerable!
Bash Test

If the only output from the test command is the following, your Bash is safe from Shellshock:

Bash Test

Continue reading

If you have to dig in to logs files to investigate a problem, 1: you have failed straight away but i won’t go in to that now, 2: if you have to look at them it helps if the log files are readable.

The icinga.log file has a lot of data and unfortunately the timestamps are in epoch time format.

[1411724135] SERVICE ALERT: monitor1.gb1;IOSTAT_BUSY;WARNING;HARD;5;WARNING:sda=O:5,W:0,C:0: sdb=O:4,W:1,C:0: 

Using a little perl command line magic we can convert that ugly timestamps into something more readable.

[Fri Sep 26 09:35:35 2014] SERVICE ALERT: monitor1.gb1;IOSTAT_BUSY;WARNING;HARD;5;WARNING:sda=O:5,W:0,C:0: sdb=O:4,W:1,C:0:

Just use…

perl -pe 's/(\d+)/localtime($1)/e' icinga.log |grep monitor1.gb1

or...

tail -f icinga.log | perl -pe 's/(\d+)/localtime($1)/e'

Sometimes it is helpful to be able to mount an image under the host system. If you wish to mount a QEMU / KVM disk image you could use qemu-nbd.

First you need to load the module:

 sudo modprobe nbd max_part=8

Then you can share the disk on the network and create the device entries:

 sudo qemu-nbd --connect=/dev/nbd0 file.qcow2

Then you mount it:

 mount /dev/nbd0 /mnt

When done, unmount and unshare it:

 umount /mnt/kvm
 nbd-client -d /dev/nbd0

NB: never mount a QEMU image while QEMU is using it (unless -snapshot is used), or you are likely to corrupt the filesystem on the image.

Following a recent upgrade of cacti from 0.8.7g to 0.8.7h i noticed a problem with the poller output. When the poller attempts to parse the output in order to generate rrdtool update command, the output is incorrectly interpreted as a hexadecimal number and the resulting update command looks like this:

11/16/2011 08:55:35 AM – POLLER: Poller[0] CACTI2RRD: /usr/bin/rrdtool update /var/lib/cacti/rra/server_520_333.rrd –template 1321433734:2.0177678937406E+118
Continue reading

Servers by default display information via Apache and PHP that makes them vulnerable. With Apache, the version number and installed module versions are listed at the bottom of 404 error pages and on HEAD requests. With PHP, because it runs on our servers as CGI, when it processes php scripts, it adds the “X-Powered By” and displays the version number. In both cases this is not desirable as attackers can use such information to compromise the server.
Continue reading

If you are using tsclient, a remote desktop client, and you connect in full screen mode it can be difficult to switch back to your linux session because there is no ‘connection bar’ at the top.

To toggle full screen mode, use the key combination Ctrl+Alt+Enter.