≡ Menu

enterprise linux

Critical Red hat / Fedora Linux Openssh Security Update

Last week one or more of Red Hat's servers got cracked. Now, it has been revealed that both Fedora and Red Hat servers have been compromised. As a result Fedora is changing their package signing key. The intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64
architecture only).

This update has been rated as having critical security impact. If your Red hat based server directly connected to the Internet, immediately patch up the system.

From the RHN announcement:

Last week Red Hat detected an intrusion on certain of its computer systems and took immediate action. While the investigation into the intrusion is on-going, our initial focus was to review and test
the distribution channel we use with our customers, Red Hat Network (RHN) and its associated security measures. Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than
those of official Red Hat subscribers.

Following products are affected:
=> Red Hat Desktop (v. 4)
=> Red Hat Enterprise Linux (v. 5 server)
=> Red Hat Enterprise Linux AS (v. 4)
=> Red Hat Enterprise Linux AS (v. 4.5.z)
=> Red Hat Enterprise Linux Desktop (v. 5 client)
=> Red Hat Enterprise Linux ES (v. 4)
=> Red Hat Enterprise Linux ES (v. 4.5.z)
=> Red Hat Enterprise Linux WS (v. 4)

How do I patch up my system?

Login as the root and type the following command:
# yum update

This is the main reason I don't use Fedora in a production.

More information:

Now, Red hat did not disclosed how the hell attacker got in to the server. I'd like to know more about that - was it 0 day bug or plain old good social engineering hack?

Updated for accuracy - CentOS is not affected by this bug, see the comments below.

CentOS / Red Hat Enterprise Linux 5.2 Poor NFS Performance and Solution

A few days ago I noticed that NFS performance between a web server node and NFS server went down by 50%. NFS was optimized and the only thing was updated Red Hat kernel v5.2. I also noticed same trend on CentOS 5.2 64 bit edition.

NFS server crashed each and every time web server node tried to store a large file 20-100 MB each. Read performance was fine but write performance went to hell. Finally, I had to rollback the updates. Recently, while reading Red Hat site I came across the solution.

Updated kernel packages that fix various security issues and several bugs are now available for Red Hat Enterprise Linux 5:

* a 50-75% drop in NFS server rewrite performance, compared to Red Hat
Enterprise Linux 4.6, has been resolved.

After upgrading kernel on both server and client my issue resolved:
# yum update

Paid Support From Novell / Red Hat Not Important for Linux Adoption

There is a new growing trend in enterprise, adopt community based distribution such as Ubuntu or CentOS Linux. I can confirm the same. Last month, I helped one my client to move from RHEL 4.x to CentOS and Debian boxes. I also trained their existing staff to work with Debian. This was done to cut the cost and they found that Red Hat support is not worth paying huge money. They were totally dissatisfied with the cost of support services.

Companies are increasingly choosing free community-driven Linux distributions instead of commercial offerings with conventional support options. Several factors are driving this trend, particularly dissatisfaction with the cost of support services from the major distributors. Companies that use and deploy Linux internally increasingly have enough in-house expertise to handle all of their technical needs and no longer have to rely on Red Hat or Novell.

I've client with over 500 RHEL servers. I always found that Google is the best hunting tool for solving Linux related problems. Red Hat staff will always forced to do a sysreport before you moved to 2nd or 3rd level support to get quality support (it may take 2-3 days). So what is the use of support if I had to go though tier 1 each time?

On a bright side, you may wanna use Red Hat or Novell support:

  1. If you like to point fingers at someone else with 24/7
  2. Large Business most likely going to have support option
  3. Red Hat and Novell also help to grow open source software. They pay full-time Linux developers and kernel hackers.
  4. Some kernel bugs and issues can only be fixed by vendor as there is no work around.

Personally, I use Debian and FreeBSD on all my servers. Cyberciti.biz server is powered by RHEL 5.2. I always suggest to have RHEL for all business / mission critical systems.

Read more: Analyst: Ubuntu, community distros ready for the enterprise

Red Hat Enterprise Linux 4 Kernel Bug Fix Update

Updated kernel packages that fix several bugs, while adding an enhancement are now available for Red Hat Enterprise Linux 4.

The kernel packages contain the Linux kernel, the core of any Linux operating system.

These updated packages fix the following bugs:

* the GNU libc stub resolver is a minimal resolver that works with Domain Name System (DNS) servers to satisfy requests from applications for names. The GNU libc stub resolver did not specify a source UDP port, and therefore used predictable port numbers. This could have make DNS spoofing attacks easier.

The Linux kernel has been updated to implement random UDP source ports where none are specified by an application. This allows applications, such as those using the GNU libc stub resolver, to use random UDP source ports, helping to make DNS spoofing attacks harder.

* A set of patches detailed as "sys_times: Fix system unresponsiveness during many concurrent invocation of sys_times()" and "Minor code cleanup to sys_times() call" introduced regression which caused a kernel panic under high load. These patches were reverted in the current release.

* A process could hang in an uninterruptible state while accessing application data files due to race condition in asynchronous direct I/O system calls.

* USB devices would not be detected on a PowerEdge R805 system. USB devices are now able to be detected on the aforementioned system with this update.

Further, these updated packages add the following enhancement:

* Added HDMI support for AMD ATI chipsets RS780, RV610, RV620, RV630, RV635, RV670 and RV770.

How do I upgrade my kernel on RHEL 4.x?

Type the following command as root user:
# up2date -uf

RHEL5: Linux Kernel kexec-tools bug fix update

An updated kexec-tools package that fixes a bug is now available for RHEL systems. The kexec-tools package provides tools that facilitate a new kernel to boot using the Linux kernel kexec feature, either on a normal or a panic reboot. Users of kexec-tools are advised to upgrade to this updated package, which resolves the following issue:

bt: unwind: failed to locate return link
makedumpfile corrupts vmcore on ia64: crash's bt fails to unwind

How do I fix this issue?

Type the following command as root user:
# yum update

Red Hat Enterprise Linux Security: An Updated autofs Package Available

An updated autofs package that fixes a bug is now available. The autofs utility controls the operation of the automount daemon, which automatically mounts, and then unmounts file systems after a period of inactivity. File systems can include network file systems, CD-ROMs, diskettes, and other media.

How do I update my autofs package?

Simply type the following command:
# yum update

Security Alert: Red hat / CentOS Linux Freetype Various Security Issues

Red hat issued important security update for freetype package that that fix various security issues are now available for Red Hat Enterprise Linux 3, 4, and 5. Multiple flaws were discovered in FreeType's Printer Font Binary (PFB) font-file format parser. If a user loaded a carefully crafted font-file with a program linked against FreeType, it could cause the application to crash, or possibly execute arbitrary code

The FreeType engine is a free and portable font rendering engine, developed to provide advanced font support for a variety of platforms and environments. FreeType is a library which can open and manages font files as well as efficiently load, hint and render individual glyphs. FreeType is not a font server or a complete text-rendering library.

How do I fix this issue?

Simply type the following command at a shell promot:
# yum update
Sample output:

Loading "rhnplugin" plugin
Loading "security" plugin
rhel-x86_64-server-vt-5   100% |=========================| 1.2 kB    00:00
rhel-x86_64-server-5      100% |=========================| 1.2 kB    00:00
Skipping security plugin, no data
Setting up Update Process
Resolving Dependencies
Skipping security plugin, no data
--> Running transaction check
---> Package freetype.i386 0:2.2.1-20.el5_2 set to be updated
---> Package freetype.x86_64 0:2.2.1-20.el5_2 set to be updated
--> Finished Dependency Resolution
Dependencies Resolved
 Package                 Arch       Version          Repository        Size
 freetype                i386       2.2.1-20.el5_2   rhel-x86_64-server-5  313 k
 freetype                x86_64     2.2.1-20.el5_2   rhel-x86_64-server-5  311 k
Transaction Summary
Install      0 Package(s)
Update       2 Package(s)
Remove       0 Package(s)
Total download size: 624 k
Is this ok [y/N]: y
Downloading Packages:
(1/2): freetype-2.2.1-20. 100% |=========================| 311 kB    00:00
(2/2): freetype-2.2.1-20. 100% |=========================| 313 kB    00:00
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating  : freetype                     ######################### [1/4]
  Updating  : freetype                     ######################### [2/4]
  Cleanup   : freetype                     ######################### [3/4]
  Cleanup   : freetype                     ######################### [4/4]
Updated: freetype.i386 0:2.2.1-20.el5_2 freetype.x86_64 0:2.2.1-20.el5_2