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

You can follow the instructions below to set a custom php.ini file per user when using FastCGI with cPanel on your server.

Step 1 – Make a backup copy of your cPanel PHP wrapper script:

cp -frp /usr/local/cpanel/cgi-sys/php5 /usr/local/cpanel/cgi-sys/php5.bk

Step 2 – Edit the cPanel PHP wrapper script:

vim /usr/local/cpanel/cgi-sys/php5

Add the following line above exec /usr/bin/php:

[[ -f ~/public_html/php.ini ]] && exec /usr/bin/php -c ~/public_html/php.ini

The file should now look like:

#!/bin/sh

# If you customize the contents of this wrapper script, place
# a copy at /var/cpanel/conf/apache/wrappers/php5
# so that it will be reinstalled when Apache is updated or the
# PHP handler configuration is changed

[[ -f ~/public_html/php.ini ]] && exec /usr/bin/php -c ~/public_html/php.ini
exec /usr/bin/php

Step 3 – Now you will want to copy the PHP wrapper script to a more permanent location. This will ensure the settings are saved if you ever recompile Apache.

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'

On April 7, 2014 a vulnerability [CVE-2014-0160 – know as Heartbleed] was released that could allow attackers to view sensitive information in a server’s memory such as secret keys and passwords. There are a million and 1 posts around the internet now with more details on this vulnerability so i am not going to go in to details here.

You will find a nice tool on github to test if your system is vulnerable. To use this tool you must have Go 1.2.x installed.
Continue reading

While trying to clear up an unused Logical Volume i came across this error:

#lvremove /dev/datavol/testbuild
Can't remove open logical volume "testbuild"

After a little investigation i could see the Open status for this LV was set to 2:

#dmsetup info -c  /dev/datavol/testbuild
Name              Maj Min Stat Open Targ Event  UUID                                                                
datavol-testbuild 252   2 L--w    2    1      0 LVM-6d36fbop48S1KvuFtoUnn8vFJyoRSKANfX5ViDNAl3h2d3WiAIcou4oprHDRJpvB

I had 2 patitions setup in this LV so i removed them using the commands below

#dmsetup remove /dev/mapper/datavol-testbuild2

#dmsetup remove /dev/mapper/datavol-testbuild1

The open status was now 0 so i could remove the LV.

  --- Logical volume ---
  LV Name                /dev/datavol/testbuild
  VG Name                datavol
  LV UUID                fX5ViD-NAl3-h2d3-WiAI-cou4-oprH-DRJpvB
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                40.00 GiB
  Current LE             10240
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:2

Remove the LV:

# lvremove /dev/datavol/testbuild
Do you really want to remove active logical volume testbuild? [y/n]: y
  Logical volume "testbuild" successfully removed

On each renewal of our ssl cert i always forget how i manage to get openfire to read a new certificate. Finally found some notes which seems to just work – Credit to The_Spider on igniterealtime.org forum for providing clear instructions.

Stop Openfire then merge your root CA with your certificate:

cat example.com.cert startssl.class2.ca > example.com.TempCert

Convert your existing Private Key and new merged certificate to the pkcs12 format. (This step requires you create a password, I am going to use the default password for simplicity. “changeit”)

openssl pkcs12 -export -in example.com.TempCert -inkey example.com.private -out example.com.pkcs12 -name example.com

Merge your private key and cert to OpenFire’s private Keystore.

keytool -importkeystore -deststorepass changeit -destkeypass changeit -destkeystore /opt/openfire/resources/security/keystore -srckeystore example.com.pkcs12 -srcstoretype PKCS12 -srcstorepass changeit -alias example.com

Start OpenFire

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.

Google engineering intern Andrew Munn has launched into a detailed explanation on Google+ as to why many Android devices are significantly more sluggish and less responsive in terms of user interface and experience than comparable iOS and Windows Phone 7 devices. The root of the problem? Inoptimal priority queuing on Android OS. On one side, iOS has graphics rendering queued as a real-time priority, thereby letting users self-manage which priorities are to be rendered in the background. On the flip side, Android views graphics rendering as a normal priority. As a result, Android devices tend to become more sluggish when they’re trying to perform other tasks simultaneously.

 

Continue reading