It’s been a while, but that doesn’t necessarily mean it was vaporware! 😉 As promised in Part 1, the system call tool that mimicks GNU fileutils commands is in the code listing below. Support for any additional commands is welcome; if anybody adds more feel free to e-mail your source code. Extension should be fairly straightforward given then “if(){}else if{}else{}” template. Just simply add another else-if code block with appropriate command line argument parsing. It’s too bad you can’t really do closures in C, but a likely approach to increasing this tool’s modularity is the use of function pointers. Of course new commands don’t have to be from GNU fileutils–mixing and matching Linux system calls in C has limitless possibilities.

Speaking of GNU, I stumbled across an extremely useful GNU project called parallel. Essentially, it’s a multi-threaded version of xargs(1p). I’ve been including it in a lot of bash scripts I’ve written recently. It doesn’t seem to be part of the default install for any operating system distributions, yet; maybe when it evolves into something even more awesome it’ll become mainstream. 🙂 Suprisingly, I was even able to compile it on SUA/Interix without any problems. The only complaint I have about it is the Perl source language (not that I have anything against Perl). I simply feel that the parallelization processes could be that much faster if written in C. Maybe I’ll perlcc(1) it or something. Okay, then–without any further adieu, here’s the code for syscaller:

Please note that some of the lines of code in this article are truncated due to how WordPress’s CSS renders the font text. Although, you’ll still receive every statement in its entirety when you copy it to your clipboard. The next specimen is similar to the netstat emulating shell script from Part 1. It loops through the procfs PID number directories and parses their contents to make it look like you’re running the actual /bin/ps, even though you’re inside a misconfigured root directory that doesn’t have that binary. It also has some useful aliases and a simple version of uptime(1).

The content of this blog post is intended for the hackers that have found themselves frustrated as a result of privilege escalation difficulties in the context of a chroot(2) jail environment. Such a situation can occur because of shell account access where the environment or shell itself have been restricted, successfully executing shellcode via overflow in the context of a network daemon, etc. Before I begin, I’d just like to mention that newer versions of Sun Microsystems’ Solaris (now, the Oracle Solaris operating system) Containers, also known as zones serve similar purpose to chroot prisons. Also, I won’t be discussing kernel space memory corruption as a means of subverting a jail; this subject was touched upon in a Phrack article entitled Smashing The Kernel Stack For Fun And Profit (P60-6).

First, I’d like to state that sometimes much information can be gathered simply by looking around the jailed directory hierarchy, since system administrators occasionally copy files from the real root filesystem into the jail. For example, /etc/ld.so.cache may contain pathnames to libraries that exist in the real root, allowing network daemons and other programs that are dynamically linked with vulnerable libraries to be targeted.

Second, it is not entirely uncommon for procfs to be mounted at the usual /proc location within the jail since it’s a prerequisite for many useful utilities. This allows more information to be gathered such as network configuration settings, Internet connections, running processes, and more.. For example, information displayed by netstat(8) can be gleaned from /proc/net/tcp and /proc/net/udp even though the netstat binary may not exist in the chroot environment. The bash shell script below demonstrates this ability:

If the chmod binary is not present in the jail then you can make the script usable by simply running: bash script.sh, source script.sh, . script.sh, etc. These commands will work even if the /home directory is mounted with the noexec option since bash (or whatever shell you’re using) must be in a directory on a partition that allows execution such as /bin. Of course, you’re out of luck in that particular scenario if you want to execute an ELF binary under $HOME, although some combination of indirect attack techniques may still lead to the desired effect.

Similarly, a makeshift route(8) script can be created to display information about the IP routing table which is accessible through /proc/net/route. Lots of useful information can be gathered from procfs in this manner. Refer to the manual pages and /usr/src/linux/Documentation/filesystems/proc.txt for many more possibilities.

If file transfer services such as SCP and (S)FTP are not configured for the prison, then binary files can still be copied to the target system. If SSH access is available then cat file.bin | ssh -l user@host.dom ‘cat>file.bin’ will suffice. If SSH is not an option, then it shouldn’t be very difficult to write a script locally that converts the file contents to hexadecimal and provides the needed echo -ne ‘\x90’ styled commands which will construct the file auto-magically on the remote system.

In the second part of this blog duo I will provide the source code to a custom job shell that has built-in commands based on system call prototypes in order to circumvent the absence of important commands from packages like GNU fileutils, i.e. chmod(1), chown(1), and others. I’ll be demonstrating another shell script that takes advantage of procfs presence as well so check back soon for more useful tidbits. You can find notifications of new System of Systems blog postings on our Twitter feed, @secobjs.

Every once in a while there are security vulnerabilities publicized that can be exploited with a single command. This week, Security Objectives published advisories for two such vulnerabilities (SECOBJADV-2008-04 and SECOBJADV-2008-05) which I’ll be describing here. I’ll also be revisiting some one-line exploits from security’s past for nostalgia’s sake and because history tends to repeat itself.

Both issues that were discovered are related to Symantec’s Veritas Storage Foundation Suite. They rely on the default set-uid root bits being set on the affected binaries. Before Symantec and Veritas combined, Sun package manager prompted the administrator with an option of removing the set-id bits. The new Symantec installer just went ahead and set the bits without asking (how rude!)

On to the good stuff.. The first weakness is an uninitialized memory disclosure vulnerability. It can be leveraged like so:

/opt/VRTS/bin/qiomkfile -s 65536 -h 4096 foo

Now, the contents of file .foo (note that it is a dot-file) will contain uninitialized memory from previous file system operations–usually from other users. Sensitive information can be harvested by varying the values to the -s and -h flags over a period of time.

This next one is a bit more critical in terms of privilege escalation. It is somewhat similar to the Solaris srsexec hole from last year. Basically, you can provide any file’s pathname on the command line and have it displayed on stderr. As part of the shell command, I’ve redirected standard error back to standard output.

/opt/VRTSvxfs/sbin/qioadmin -p /etc/shadow / 2>&1

Some of these one-liner exploits can be more useful than exploits that utilize shellcode. Kingcope’s Solaris in.telnetd exploit is a beautiful example of that. The really interesting thing about that one was its resurrection–it originally became well-known back in 1994. In 2007, Kingcope’s version won the Pwnie award for best server-side bug.

telnet -l -fusername hostname

Let’s not forget other timeless classics such as the cgi-bin/phf bug, also from the mid-nineties:

I’m not including exploits that have pipes/semi-colons/backticks/etc. in the command-line because that’s really more than one command being executed. Since the “Ping of Death” is a single command from a commonly installed system utility I’ll be including it here as well. I consider it a true denial of service attack since it does not rely on bandwidth exhaustion: