Linux Kernel Bug: Bug 516949 – (CVE-2009-2692)

Rai    Linux    

Release Found: Red Hat Enterprise Linux 3, 4, 5, and Red Hat Enterprise MRG.

Problem

The flaw identified by CVE-2009-2692 (Red Hat Bugzilla bug 516949) describes an issue in the SOCKOPS_WRAP macro in the Linux kernel, versions 2.4.4 and later, and 2.6.0 and later. This macro did not initialize the sendpage operation in the proto_ops structure correctly. This flaw was addressed via the upstream git commits c18d0fe5 for the 2.4 kernel, and e6949583 for the 2.6 kernel. On systems without these patches, this flaw can lead to a local denial of service or privilege escalation.

This issue has been rated as having important security impact by the Red Hat Security Response Team.

Mitigation

Future updates will address this flaw for Red Hat Enterprise Linux 3, 4, 5, and Red Hat Enterprise MRG. Until these updates are released, it is possible to reduce the risk and mitigate this flaw by blacklisting the kernel modules of the affected protocols.

The mitigation steps outlined below will not work if the modules are already loaded. If the modules are loaded and cannot be removed, for example, via “modprobe -r”, a reboot will be required before the changes take effect.

The “install” command is used to direct the system to run the “/bin/true” command instead of inserting the modules if they are called:

Red Hat Enterprise Linux 3

Add the following entry to the end of the /etc/modules.conf file:

install bluez /bin/true

Note: the kernel-unsupported package provides the bluez module. This module is not available if you do not have kernel-unsupported installed.

Red Hat Enterprise Linux 4 and 5

Add the following entries to the end of the /etc/modprobe.conf file:

install pppox /bin/true
install bluetooth /bin/true
install sctp /bin/true

The sctp module cannot be unloaded from a running kernel if the module is already loaded; therefore, the above changes for /etc/modprobe.conf on Red Hat Enterprise Linux 4 and 5 require a reboot to take effect.

Red Hat Enterprise MRG

Add the following entries to the end of the /etc/modprobe.conf file:

install pppox /bin/true
install bluetooth /bin/true
install appletalk /bin/true
install ipx /bin/true
install sctp /bin/true

The modules listed above are not exhaustive, but should prevent the publicly-circulated exploit for this issue from working correctly, as this is the list of protocols (relevant to Red Hat Enterprise Linux) known to be affected.

More information can be found here.

Sudo error: Sorry, you must have a tty to run sudo

Rai    Linux     configuration, error, fix, Linux, permission, rsync, sudo, troubleshoot, tty, user, visudo

From time to time, we perform remote actions on the servers that we manage, including, but not limited to, automated file transfers. For this, rsync is used to simplify the operation and until recently, I encountered this weird error:

sudo: sorry, you must have a tty to run sudo

But where on this bloody earth did that error came from? All was going well until a new server was added to the pool of money-making machines and powerful enough to throw me off guard. This can’t be happening! I own these machines, I built them from scratch and configured them exactly the way I built the other servers! I could not be any wrong-er, the server must be leading an uprising against me!

Okay, that was an exaggeration (or paranoia). But it is true that the server has the same configuration as the rest. Except for one little line of default configuration:

Defaults requiretty

Comment out this line in visudo (must be root to edit) and everything should checkout.

PinoyTux Gets a Makeover!

Rai    Linux    

It’s been months since I paid the attention my blog deserves. Well, what do you know, I finally found the guts to upgrade my blog. So to make long story short, I upgraded to Wordpress 2.8.4, installed a beautiful new theme and voila! A fresh-looking blog.

The only thing missing is the logo at the header, which I will take care of in the morning. But for now, the goddess who created this beautiful blog needs to get her beauty sleep.

Ciao!

How to Create Upside Down Letters in Posts and Comments

Rai    Linux     characters, comments, facebook, inverted, letters, myspace, plurk, posts, text, twitter, upside down, words

Okay, this is totally random but really cool. I found out that you can write posts or comments with the letters upside down! The inverted text is created by the cool JavaScript found in SevenWires.com.

˙ɯoɔ˙sǝɹıʍuǝʌǝs uı punoɟ ʇdıɹɔsɐʌɐɾ ןooɔ ǝɥʇ ʎq pǝʇɐǝɹɔ sı ʇxǝʇ pǝʇɹǝʌuı ǝɥʇ ¡uʍop ǝpısdn sɹǝʇʇǝן ǝɥʇ ɥʇıʍ sʇuǝɯɯoɔ ɹo sʇsod ǝʇıɹʍ uɐɔ noʎ ʇɐɥʇ ʇno punoɟ ı ˙ןooɔ ʎןןɐǝɹ ʇnq ɯopuɐɹ ʎןןɐʇoʇ sı sıɥʇ ‘ʎɐʞo

How to Fix PECL PHP Error: /bin/sh: bad interpreter: Permission denied

Rai    Linux     bash, denied, error, fix, how, interpreter, Linux, pear, pecl, permission, php, red hat, server, xdebug

I recently tried installing xdebug on a RHEL 4 machine, and somehow, the server decided that it should refuse having xdebug installed. As if running a heavy Java app is not enough, I decided to add more processes for the server to run. And it looks like the server has got me:

[root@server src]# pecl install xdebug
downloading xdebug-2.0.5.tgz ...
Starting to download xdebug-2.0.5.tgz (287,621 bytes)
.............done: 287,621 bytes
12 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
/usr/local/bin/phpize: /tmp/pear/temp/xdebug/build/shtool: /bin/sh: bad interpreter: Permission denied

So, like I always do, I tackle the problem with my handy tool: Google. I found out that this error occurs when /tmp is mounted as read-only (ro). You can check this by looking at the /etc/fstab file and check the /tmp partition.

Okay, now I know what the problem is. How do I get over this?

Lazy that I am, I moved the /tmp/pear directory, and create a symlink to the root directory.

[root@server src]# mv /tmp/pear /tmp/pear-ori
[root@server src]# mkdir /root
[root@server src]# ln -s /tmp/pear /root/tmp/pear

Now that the directory from where the PECL scripts are running is in /root, the installation should go smoothly.

Another way to go around this is to remount the /tmp:

[root@server src]# mount -oremount,exec /tmp

I have not tried the above command because I thought that creating symlink is a safer approach rather than messing with the mounts.

If there are other ways to fix this, let me know using the comment box below.