Archive for the ‘Articles’ Category

How to display security updates by yum

Monday, December 7th, 2009

Ref: http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/

Ref: http://www.cyberciti.biz/faq/redhat-fedora-centos-linux-yum-installs-security-updates/

Install Plugin

Type the following command:
# yum install yum-security

How Do I Display Available Security Updates?

Type the following command:
# yum list-security
Sample Outputs:

Loaded plugins: rhnplugin, security
RHSA-2009:1148-1 security httpd-2.2.3-22.el5_3.2.x86_64
RHSA-2009:1148-1 security httpd-devel-2.2.3-22.el5_3.2.i386
RHSA-2009:1148-1 security httpd-manual-2.2.3-22.el5_3.2.x86_64
RHSA-2009:1148-1 security mod_ssl-1:2.2.3-22.el5_3.2.x86_64
list-security done

To list all updates that are security relevant, and get a reutrn code on whether there are security updates use:
# yum --security check-update
To get a list of all BZs that are fixed for packages you have installed use:
# yum list-security bugzillas
To get the information on advisory RHSA-2009:1148-1 use:
# yum info-security RHSA-2009:1148-1
Sample Outputs:

Loaded plugins: rhnplugin, security

===============================================================================
  RHSA-2009:1148
===============================================================================
  Update ID : RHSA-2009:1148-1
    Release :
       Type : security
     Status : final
     Issued : 2009-07-08 23:00:00
       Bugs : 509125 - None
	    : 509375 - None
       CVEs : CVE-2009-1890
	    : CVE-2009-1891
Description : Important: httpd security update  \The Apache HTTP Server is a
            : popular Web server.  A denial of service flaw was
            : found in the Apache mod_proxy module when it was
            : used as a reverse proxy. A remote attacker could
            : use this flaw to force a proxy process to consume
            : large amounts of CPU time. (CVE-2009-1890)  A
            : denial of service flaw was found in the Apache
            : mod_deflate module. This module continued to
            : compress large files until compression was
            : complete, even if the network connection that
            : requested the content was closed before
            : compression completed. This would cause
            : mod_deflate to consume large amounts of CPU if
            : mod_deflate was enabled for a large file.
            : (CVE-2009-1891)  All httpd users should upgrade to
            : these updated packages, which contain backported
            : patches to correct these issues. After installing
            : the updated packages, the httpd daemon must be
            : restarted for the update to take effect.
      Files : mod_ssl-2.2.3-22.el5_3.2.x86_64.rpm
	    : httpd-devel-2.2.3-22.el5_3.2.i386.rpm
	    : httpd-2.2.3-22.el5_3.2.x86_64.rpm
	    : httpd-devel-2.2.3-22.el5_3.2.x86_64.rpm
	    : httpd-manual-2.2.3-22.el5_3.2.x86_64.rpm
	    : mod_ssl-2.2.3-22.el5_3.2.i386.rpm
	    : httpd-2.2.3-22.el5_3.2.i386.rpm
	    : httpd-manual-2.2.3-22.el5_3.2.i386.rpm
info-security done

Ref:http://www.cyberciti.biz/faq/redhat-fedora-centos-linux-yum-installs-security-updates/

To get an info list of the latest packages which contain fixes for Bugzilla 3595; CVE # CVE-2009-1890 and advisories RHSA-2009:1148-1, use:
# yum --bz 3595 --cve CVE-2009-1890 --advisory RHSA-2009:1148-1 info updates

How Do I Install All The Security Updates Only?

Type the following command to download and install all the available security updates:
# yum update --security

Critical vulnerability in the Linux kernel affects all versions since 2001

Thursday, August 27th, 2009

Ref :http://www.h-online.com/security/Red-Hat-Novell-and-CentOS-update-for-kernel-vulnerability-Update–/news/114072

Google security specialists Tavis Ormandy and Julien Tiennes report that a critical security vulnerability in the Linux kernel affects all versions of 2.4 and 2.6 since 2001, on all architectures. The vulnerability enables users with limited rights to get root rights on the system. The cause is a NULL pointer dereference in connection with the initialisation of sockets for rarely used protocols.

A pointer structure usually defines what operations a socket supports, for example accept, bind and so on. If, say, the accept operation is not implemented, it should point to a predefined component such as sock_no_accept. This is evidently not the case with all implemented protocols. The report mentions PF_BLUETOOTH, PF_IUCV, PF_INET6 (with IPPROTO_SCTP), PF_PPPOX and PF_ISDN, among others, as having unimplemented operations. Some pointers remain uninitialised, and this can be exploited in conjunction with the function sock_sendpage to execute code with root rights.

Ormandy and Tiennes believe that all Linux version 2.4 and 2.6 since May 2001 are affected, which means 2.4.4 up to and including 2.4.37.4, as well as 2.6.0 up to and including 2.6.30.4. Instead of fixing all incompletely implemented protocols, the kernel developers have simply remapped sock_sendpage to the function kernel_sendpage, which also handles the case of an uninitialised pointer. So far, this correction has only gone into the kernel repository.

However, a new official kernel version can be expected shortly since an exploit for the vulnerability is already publicly available. The author of the code is again Brad Spengler, who published a root exploit for the Linux kernel in mid-July. In a short test on a completely patched Ubuntu 8.10 in the heise Security office, The H’s associates found that the new exploit gave root access to the system.

Ormandy and Tiennes say, however, that the exploit will not work on current kernels with mmap_min_addr support if a number greater than zero is defined by means of sysctl as the value for vm.mmap_min_addr.

Patches for this problems are :

http://lists.centos.org/pipermail/centos-announce/2009-August/016062.html

http://lists.centos.org/pipermail/centos-announce/2009-August/016062.html

How to Rebuilding failed Linux software RAID

Friday, August 14th, 2009

Ref: http://aplawrence.com/Linux/rebuildraid.html

Recently I had a hard drive fail. It was part of a Linux software RAID 1 (mirrored drives), so we lost no data, and just needed to replace hardware. However, the raid does requires rebuilding. A hardware array would usually automatically rebuild upon drive replacement, but this needed some help.

When you look at a “normal” array, you see something like this:

# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md2 : active raid1 hda3[1] hdb3[0]
262016 blocks [2/2] [UU]

md1 : active raid1 hda2[1] hdb2[0]
119684160 blocks [2/2] [UU]

md0 : active raid1 hda1[1] hdb1[0]
102208 blocks [2/2] [UU]

unused devices:

That’s the normal state – what you want it to look like. When a drive has failed and been replaced, it looks like this:

Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 hda1[1]
102208 blocks [2/1] [_U]

md2 : active raid1 hda3[1]
262016 blocks [2/1] [_U]

md1 : active raid1 hda2[1]
119684160 blocks [2/1] [_U]
unused devices:

Notice that it doesn’t list the failed drive parts, and that an underscore appears beside each U. This shows that only one drive is active in these arrays – we have no mirror.

Another command that will show us the state of the raid drives is “mdadm”

# mdadm -D /dev/md0
/dev/md0:
Version : 00.90.00
Creation Time : Thu Aug 21 12:22:43 2003
Raid Level : raid1
Array Size : 102208 (99.81 MiB 104.66 MB)
Device Size : 102208 (99.81 MiB 104.66 MB)
Raid Devices : 2
Total Devices : 1
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Fri Oct 15 06:25:45 2004
State : dirty, no-errors
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0

Number Major Minor RaidDevice State
0 0 0 0 faulty removed
1 3 1 1 active sync /dev/hda1
UUID : f9401842:995dc86c:b4102b57:f2996278

As this shows, we presently only have one drive in the array.

Although I already knew that /dev/hdb was the other part of the raid array, you can look at /etc/raidtab to see how the raid was defined:

raiddev /dev/md1
raid-level 1
nr-raid-disks 2
chunk-size 64k
persistent-superblock 1
nr-spare-disks 0
device /dev/hda2
raid-disk 0
device /dev/hdb2
raid-disk 1
raiddev /dev/md0
raid-level 1
nr-raid-disks 2
chunk-size 64k
persistent-superblock 1
nr-spare-disks 0
device /dev/hda1
raid-disk 0
device /dev/hdb1
raid-disk 1
raiddev /dev/md2
raid-level 1
nr-raid-disks 2
chunk-size 64k
persistent-superblock 1
nr-spare-disks 0
device /dev/hda3
raid-disk 0
device /dev/hdb3
raid-disk 1

To get the mirrored drives working properly again, we need to run fdisk to see what partitions are on the working drive:

# fdisk /dev/hda

Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 14946 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 13 104391 fd Linux raid autodetect
/dev/hda2 14 14913 119684250 fd Linux raid autodetect
/dev/hda3 14914 14946 265072+ fd Linux raid autodetect

Duplicate that on /dev/hdb. Use “n” to create the parttions, and “t” to change their type to “fd” to match. Once this is done, use “raidhotadd”:

# raidhotadd /dev/md0 /dev/hdb1
# raidhotadd /dev/md1 /dev/hdb2
# raidhotadd /dev/md2 /dev/hdb3

The rebuilding can be seen in /proc/mdstat:

# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 hdb1[0] hda1[1]
102208 blocks [2/2] [UU]

md2 : active raid1 hda3[1]
262016 blocks [2/1] [_U]

md1 : active raid1 hdb2[2] hda2[1]
119684160 blocks [2/1] [_U]
[>………………..] recovery = 0.2% (250108/119684160) finish=198.8min speed=10004K/sec
unused devices:

The md0, a small array, has already completed rebuilding (UU), while md1 has only begun. After it finishes, it will show:

# mdadm -D /dev/md1
/dev/md1:
Version : 00.90.00
Creation Time : Thu Aug 21 12:21:21 2003
Raid Level : raid1
Array Size : 119684160 (114.13 GiB 122.55 GB)
Device Size : 119684160 (114.13 GiB 122.55 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent

Update Time : Fri Oct 15 13:19:11 2004
State : dirty, no-errors
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Number Major Minor RaidDevice State
0 3 66 0 active sync /dev/hdb2
1 3 2 1 active sync /dev/hda2
UUID : ede70f08:0fdf752d:b408d85a:ada8922b

I was a little surprised that this process wasn’t entirely automatic. There’s no reason it couldn’t be. This is an older Linux install; I don’t know if more modern versions will just automatically rebuild.