This post could be summarised with the following words:

Return oriented programming has been proven to be a very effective way of circumventing data execution prevention features like ASLR present in modern operating systems, but the attacker needs to know the binary structure of the target executable in order to extract the so-called borrowed chunks of code. Here a generic binary exploitation technique will be covered which in some cases requires no knowledge about the running program.

Contexts and switches

A clever way to alter the control flow of the program by using context control will be described. A program execution context comprises the CPU’s registers, the program counter plus other operating system specific data at any point in time. A context switch is the process of storing and restoring the state of a process so that execution can be resumed from the same point at a later time. There are two types of context switches: software and hardware.

In this post I will cover the software context switch used in the process of a task returning from a software signal on 64bits. The Linux implementation of signals is fully POSIX-compliant, and the data used to recover the task from a previus state (the interrupted context: registers, program counter, signal mask, etc.) is be saved in a ucontext_t structure on the stack for the thread, along with the trampoline return address. Signal handlers installed with the SA_SIGINFO flag are able to examine this ucontext_t structure. The definition of the structure ucontext can be seen in the include/uapi/asm-generic/ucontext.h header file:

#ifndef __ASM_GENERIC_UCONTEXT_H
#define __ASM_GENERIC_UCONTEXT_H

struct ucontext {
        unsigned long     uc_flags;
        struct ucontext  *uc_link;
        stack_t           uc_stack;
        struct sigcontext uc_mcontext;
        sigset_t          uc_sigmask;   /* mask last for extensibility */
};

#endif /* __ASM_GENERIC_UCONTEXT_H */

The structure sigcontext, which holds the saved state of the task (registers, etc) can be examined in the arch/x86/include/asm/sigcontext.h header file:

struct sigcontext {
        unsigned long r8;
        unsigned long r9;
        unsigned long r10;
        unsigned long r11;
        unsigned long r12;
        unsigned long r13;
        unsigned long r14;
        unsigned long r15;
        unsigned long di;
        unsigned long si;
        unsigned long bp;
        unsigned long bx;
        unsigned long dx;
        unsigned long ax;
        unsigned long cx;
        unsigned long sp;
        unsigned long ip;
        unsigned long flags;
        unsigned short cs;
        unsigned short gs;
        unsigned short fs;
        unsigned short __pad0;
        unsigned long err;
        unsigned long trapno;
        unsigned long oldmask;
        unsigned long cr2;

        /*
         * fpstate is really (struct _fpstate *) or (struct _xstate *)
         * depending on the FP_XSTATE_MAGIC1 encoded in the SW reserved
         * bytes of (struct _fpstate) and FP_XSTATE_MAGIC2 present at the end
         * of extended memory layout. See comments at the definition of
         * (struct _fpx_sw_bytes)
         */
        void __user *fpstate;           /* zero when no FPU/extended context */
        unsigned long reserved1[8];
};

The struct _fpstate __user *fpstate is defined in the arch/x86/include/uapi/asm/sigcontext.h header file:

struct _fpstate {
        /* Regular FPU environment */
        unsigned long   cw;
        unsigned long   sw;
        unsigned long   tag;
        unsigned long   ipoff;
        unsigned long   cssel;
        unsigned long   dataoff;
        unsigned long   datasel;
        struct _fpreg   _st[8];
        unsigned short  status;
        unsigned short  magic;          /* 0xffff = regular FPU data only */

        /* FXSR FPU environment */
        unsigned long   _fxsr_env[6];   /* FXSR FPU env is ignored */
        unsigned long   mxcsr;
        unsigned long   reserved;
        struct _fpxreg  _fxsr_st[8];    /* FXSR FPU reg data is ignored */
        struct _xmmreg  _xmm[8];
        unsigned long   padding1[44];

        union {
                unsigned long   padding2[12];
                struct _fpx_sw_bytes sw_reserved; /* represents the extended
                                                   * state info */
        };
};

Finally, the signal information structure struct siginfo is available in include/uapi/asm-generic/siginfo.h:

From include/uapi/asm-generic/siginfo.h:

typedef struct siginfo {
        int si_signo;
        int si_errno;
        int si_code;

        union {
                int _pad[SI_PAD_SIZE];

                /* kill() */
                struct {
                        __kernel_pid_t _pid;    /* sender's pid */
                        __ARCH_SI_UID_T _uid;   /* sender's uid */
                } _kill;

                /* POSIX.1b timers */
                struct {
                        __kernel_timer_t _tid;  /* timer id */
                        int _overrun;           /* overrun count */
                        char _pad[sizeof( __ARCH_SI_UID_T) - sizeof(int)];
                        sigval_t _sigval;       /* same as below */
                        int _sys_private;       /* not to be passed to user */
                } _timer;

                /* POSIX.1b signals */
                struct {
                        __kernel_pid_t _pid;    /* sender's pid */
                        __ARCH_SI_UID_T _uid;   /* sender's uid */
                        sigval_t _sigval;
                } _rt;

                /* SIGCHLD */
                struct {
                        __kernel_pid_t _pid;    /* which child */
                        __ARCH_SI_UID_T _uid;   /* sender's uid */
                        int _status;            /* exit code */
                        __ARCH_SI_CLOCK_T _utime;
                        __ARCH_SI_CLOCK_T _stime;
                } _sigchld;

                /* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
                struct {
                        void __user *_addr; /* faulting insn/memory ref. */
#ifdef __ARCH_SI_TRAPNO
                        int _trapno;    /* TRAP # which caused the signal */
#endif
                        short _addr_lsb; /* LSB of the reported address */
                } _sigfault;

                /* SIGPOLL */
                struct {
                        __ARCH_SI_BAND_T _band; /* POLL_IN, POLL_OUT, POLL_MSG */
                        int _fd;
                } _sigpoll;

                /* SIGSYS */
                struct {
                        void __user *_call_addr; /* calling user insn */
                        int _syscall;   /* triggering system call number */
                        unsigned int _arch;     /* AUDIT_ARCH_* of syscall */
                } _sigsys;
        } _sifields;
} __ARCH_SI_ATTRIBUTES siginfo_t;

As a summary, the the following kernel source files play a part in this technique:

arch/x86/include/uapi/asm/sigcontext32.h (32bits)
   	struct _fpstate_ia32
   	struct sigcontext_ia32
arch/x86/include/uapi/asm/sigcontext.h
   	struct _fpstate
	#ifndef __KERNEL__
   	 	struct sigcontext (contains void __user *fpstate; )
	#endif /* !__KERNEL__ */
arch/x86/include/asm/sigcontext.h
 	#include <uapi/asm/sigcontext.h>
   	struct sigcontext ( contains void __user *fpstate; )</pre>

The good thing about storing this data on the stack is that the kernel does not need to remember the signals it delivered, but the bad point is that It can be forged.

When switching context, the kernel will execute setup_rt_frame, where all user-space registers are saved and the kernel stack frame return address is modified to point to the handler of the installed signal handler. A small sequence of code jumper is put on the user stack which will return us to kernel space once the signal handler has finished.

From arch/x86/kernel/signal.c:

static int
setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
                struct pt_regs *regs)
{
        int usig = signr_convert(sig);
        sigset_t *set = sigmask_to_save();
        compat_sigset_t *cset = (compat_sigset_t *) set;

        /* Set up the stack frame */
        if (is_ia32_frame()) {
                if (ka->sa.sa_flags & SA_SIGINFO)
                        return ia32_setup_rt_frame(usig, ka, info, cset, regs);
                else
                        return ia32_setup_frame(usig, ka, cset, regs);
        } else if (is_x32_frame()) {
                return x32_setup_rt_frame(usig, ka, info, cset, regs);
        } else {
                return __setup_rt_frame(sig, ka, info, set, regs);
        }
}

From arch/x86/kernel/signal.c:

static int __setup_rt_frame(int sig, struct k_sigaction *ka, siginfo_t *info,
                            sigset_t *set, struct pt_regs *regs)
{
        struct rt_sigframe __user *frame;
        void __user *fp = NULL;
        int err = 0;

        frame = get_sigframe(ka, regs, sizeof(struct rt_sigframe), &fp);

        if (!access_ok(VERIFY_WRITE, frame, sizeof(*frame)))
                return -EFAULT;

        if (ka->sa.sa_flags & SA_SIGINFO) {
                if (copy_siginfo_to_user(&frame->info, info))
                        return -EFAULT;
        }

        put_user_try {
                /* Create the ucontext.  */
                if (cpu_has_xsave)
                        put_user_ex(UC_FP_XSTATE, &frame->uc.uc_flags);
                else
                        put_user_ex(0, &frame->uc.uc_flags);
                put_user_ex(0, &frame->uc.uc_link);
                err |= __save_altstack(&frame->uc.uc_stack, regs->sp);

                /* Set up to return from userspace.  If provided, use a stub
                   already in userspace.  */
                /* x86-64 should always use SA_RESTORER. */
                if (ka->sa.sa_flags & SA_RESTORER) {
                        put_user_ex(ka->sa.sa_restorer, &frame->pretcode);
                } else {
                        /* could use a vstub here */
                        err |= -EFAULT;
                }
        } put_user_catch(err);

        err |= setup_sigcontext(&frame->uc.uc_mcontext, fp, regs, set->sig[0]);
        err |= __copy_to_user(&frame->uc.uc_sigmask, set, sizeof(*set));

        if (err)
                return -EFAULT;

        /* Set up registers for signal handler */
        regs->di = sig;
        /* In case the signal handler was declared without prototypes */
        regs->ax = 0;

        /* This also works for non SA_SIGINFO handlers because they expect the
           next argument after the signal number on the stack. */
        regs->si = (unsigned long)&frame->info;
        regs->dx = (unsigned long)&frame->uc;
        regs->ip = (unsigned long) ka->sa.sa_handler;

        regs->sp = (unsigned long)frame;

        /* Set up the CS register to run signal handlers in 64-bit mode,
           even if the handler happens to be interrupting 32-bit code. */
        regs->cs = __USER_CS;

        return 0;
}

The above code restores the exact user-register contents into the kernel stack frame (including the return address and flags register) and executes a normal return from syscall, bringing the execution flow back to the original code that jumped to the signal handler.

The stack frame image that Linux configures for signal returning assembles the following diagram:

 [-------------]
 [    STACK    ]
 [-------------]
 [   FPSTATE   ]
 [-------------]
 [   UCONTEXT  ]
 [-------------]
 [ SIGINFO+arg ]
 [-------------]

A detailed view on 64bits should assemble the following diagram:

     [------------------------------------------]
0x00 [  rt_sigreturn()      |  uc_flags         ]
0x10 [  &uc                 |  uc_stack.ss_sp   ]
0x20 [  uc_stack.ss_flags   |  uc_stack.ss_size ]
0x30 [  r8                  |  r9               ]
0x40 [  r10                 |  r11              ]
0x50 [  r12                 |  r13              ]
0x60 [  r14                 |  r15              ]
0x70 [  rdi                 |  rsi              ]
0x80 [  rbp                 |  rbx              ]
0x90 [  rdx                 |  rax              ]
0xA0 [  rcx                 |  rsp              ]
0xB0 [  rip                 |  eflags           ]
0xC0 [  cs / gs / fs        |  err              ]
0xD0 [  trapno              |  oldmask (unused) ]
0xE0 [  cr2 (segfault addr) |  &fpstate         ]
0xF0 [  __reserved          |  sigmask          ]
     [------------------------------------------]

Exploitation

By forging the contents of the struct sigcontext, which holds the saved registers values, setting the $rax register to the desired syscall number, setting the systemcall args properly and finally setting the program counter $rip pointing to an >syscall; ret gadget, we can effectively modify the execution flow of the program and execute the desired systemcall. Also, several SigRet frames can be chained by using the value of the saved $rsp register of the returning frame and the gadget syscall;ret.

• rax => syscall_number
• rdi => arg1
• rsi => arg2
• rdx => arg3
• r10 => arg4
• r8 => arg5
• r9 => arg6
• rip => syscall;ret
• rsp => next_frame
• cs=0×33 / gs=0×0 / fs=0×0
• &fpstate = NULL

The forged stack structure should assemble the following:

     [------------------------------------------]
0x00 [  rt_sigreturn()      |  uc_flags         ]*
0x10 [  &uc                 |  uc_stack.ss_sp   ]
0x20 [  uc_stack.ss_flags   |  uc_stack.ss_size ]
0x30 [  arg5                |  arg6             ]*
0x40 [  arg4                |  r11              ]*
0x50 [  r12                 |  r13              ]
0x60 [  r14                 |  r15              ]
0x70 [  arg1                |  arg2             ]*
0x80 [  rbp                 |  rbx              ]
0x90 [  arg3                |  syscall_number   ]*
0xA0 [  rcx                 |  next_frame       ]*
0xB0 [  syscall;ret         |  eflags           ]*
0xC0 [  cs=0x33/gs=0/fs=0   |  err              ]*
0xD0 [  trapno              |  oldmask (unused) ]
0xE0 [  cr2 (segfault addr) |  &fpstate         ]*
0xF0 [  __reserved          |  sigmask          ]
     [------------------------------------------]

As a summary, for SigReturn oriented programming, the following requirements are needed:

1. Controllable stack
2. Knowing the address of a system call gadget
3. A known writable address
4. Known file descriptor
5. Control over the RAX register

More information:

• man(2) getcontext
• man(2) setcontext
• Returning signals for fun and profit
• Context switch
• The Linux Signal Handling Model
• The GNU C Library – Signal Handling
• Wikipedia – Context switch
• Wikipedia – Getcontext
• Wikipedia – Setcontext

The post OHM 2013: Review of “Returning signals for fun and profit” appeared first on Portcullis Labs.

In their presentation, the Mailpile developers stated the concerns with cloud email to be:

• The centralisation of email storage, making mass surveillance trivial
• Poor spam filtering
• Lack of innovation with regards to F/OSS solutions
• Mass encryption is a “distant dream”
• Proprietary lock-in
• Risk of EEE tactics (Embrace, Extend, and Extinguish)
• Spam filters being used for censorship
• Incompatibility with encryption

I happen to agree with each of these issues (perhaps excepting spam). However, in the wake of PRISM, maybe we should even expand this problem space. Metadata is a big deal: It reveals (in a best case scenario) who you’ve been talking to and when, how long your messages are, and if you include attachments. Why can’t we protect this data too? Granted, this would require a somewhat more radical solution,  but I don’t see why this is a problem that couldn’t be solved. Still, it’s not fair to judge Mailpile on the basis of problems it doesn’t aim to solve, so I’ll discount this for the rest of my post.

What Mailpile propose is yet another mail user agent. Mailpile’s killer feature in the presentation appeared to be the search functionality, returning genuinely impressive search results in mere milliseconds. Beyond this, the interface was vaguely reminiscent of GMail, though obviously still in a very early stage of development. So, a nice interface, but it still doesn’t seem to address what I believe is the key issue surrounding web mail: Centralisation. From a pragmatic standpoint, no matter how simple it is to employ GPG, the standard user will not opt for it. Therefore, in my mind, the easiest way to raise the barrier to mass surveillance (the hot button topic right now) is to decentralise the storage of email, something which Mailpile fails to address.

Let’s take each of the problem bullet points, and see if Mailpile offers a solution. Mailpile at least partly addresses the following:

• Lack of innovation with regards to FOSS solutions – Does Mailpile count as innovation? That’s a matter of opinion
• Proprietary lock-in – Mailpile somewhat addresses this. If one interface supports multiple back-ends, users will find it easier to move between them
• Risk of EEE tactics (Embrace, Extend, and Extinguish) – Mailpile partly addresses this, much for the same reasons as above
• Incompatibility with encryption – Mailpile solves this problem! A locally hosted client is ideal as a solution for this problem

So, out of 8 issues identified with cloud email, Mailpile fully solves 1, and partly addresses 3. What of the other 4?

• The centralisation of email storage, making mass surveillance trivial
• Poor spam filtering
• Mass encryption is a “distant dream”
• Spam filters being used for censorship

All of these, excepting mass encryption, are really server side problems. Mailpile couldn’t hope to solve these. So, what would? Spam filtering seems to be already solved – numerous crowd-sourcing solutions exist, and in my mind this is the right way to go about solving this problem. The decentralisation of email storage just relies on more people running mail servers, and not relying on one of the big cloud providers.

The relative complexity of installing, configuring and maintaining an email server puts many off – this is what web mail really offers the average user. In my mind, the solution lies in a mail server that’s simple to deploy and maintain. Decentralising the infrastructure is what will negate the majority of the evils of web mail, not another web mail client, no matter how timely the marketing is.

On Mailpile’s own web page, they have quotes from articles on their product. These come from Wired, TechCrunch, Boing Boing, and Crowdfund Insider. These large publications should have done their homework before praising Mailpile’s security, as it does not appear to address the problems it aims to solve. It is my belief that the majority of Mailpile’s funding has come off of the back of such positive press, some of which is completely unwarranted.  It’s nice to see a positive reaction to a product with the aim of improving security and privacy for end users, but next time can we actually make sure it delivers on these goals first?

The post Mailpile: Well, they’re half right appeared first on Portcullis Labs.

All the paths at OHM 2013 reference geek culture

So, what can you do in an event like this?

This is great place to discover what other people have been doing by the talks, find new ideas and perspectives which you can debate but also to get that skill you have been craving for a long time but never had the chance to grasp, through any of the workshops. Simply walking around and let your curiosity rule can bring you a very good time as well and let you find extraordinary people including some stars that only a privileged few of us, know. It’s all great but don’t take me too seriously, entertainment is a key element on it whether you fancy dancing to some techno music or to relax by beating kids at old games in the retro gaming area.

This year, OHM was particularly well packed with its very busy program going on over 20 tents holding lectures, meetings, workshops, demonstrations and other performances about everything from cooking to politics. Dominant topics were Government Surveillance, Computer Forensics, Cryptography, Lockpicking and Vulnerability Research. There was also a lot going on with 3D printers, Arduinos, Raspberry Pi and soldering of course.

When it comes to my favourite talks I would denote the grand work performed by the Netherlands Forensic Institute which brought at least 3 great presentations on fraud investigations and memory analysis. A special reference goes to Ruud Schramp on “RAM Memory acquisition using live-BIOS modification” who describes an alternative way to acquire the RAM when firewire or userspace tools are not available. This involves swapping a BIOS on a live system to prevent ECC memory from getting wiped on reboots as well as a way to bypass live plugging PCIe failures. Epic!

The lights at OHM 2013 were something to behold

Another presentation that for sure deserves to be on my top 3 was “Hard disks: More than just block devices” where hacking these devices and its internal controllers brings a new meaning to the sentence “How to install Linux in your hard-drive” by Sprite_tm. Finally, together at the top comes the great vulnerability research on network devices with “Cisco in the sky with diamonds” by FX.

There were other highlights worth mentioning. Over video conference we had Julian Assange speaking about government surveillance, Google’s cooperation and, of course, the NSA case. Like it or not this was the moment that commanded the most attention and participation not to mention a few tears.
Another important event largely awaited was the “SIM card exploitation” by Karsten Nohl who has brought us the results of his 3 year research which exposed weaknesses on some of these cards namely regarding the supported encryption (DES).

There were more, many more, great talks for which I can only enumerate here but only after reminding you that this is a personal choice of someone who, unfortunately, could not attend all lectures and workshops talking place at the same time and had to make some tough decisions of which shall be the best to attend:

The final night party at OHM 2013

• “Returning signals for fun and profit” by Erik Bosman
• “Counter-cryptanalysis: fire retardant for the next Flame-like attack on MD5 & SHA-1” by Marc Stevens
• “Forensic hardware hacking” @NFI by Ronald van der Knijff
• “Low-cost vulnerability research: XSLT fuzzing as a case study” by Nicolas Grégoire
• “Tracy – system call injection and tracing” by Merlijn B.W. Wajer
• “Even more clipboard fun” by niekt0
• “The political and hacker origins of Twitter” by Rabble
• “Non-signature payload-based intrusion detection” by nemsis

I highly recommend you to have a look at these and other presentations even though at the time of writing, they were not available on the web site. Stay tuned as they were all recorded and new contents are coming over all the time at on the OHM 2013 wiki.

I would like to leave a note of praise to the remarkable work by the organisation and all volunteers to bring this camping festival to life. It was quite impressive to see all the preparations down to the smallest details to make everything work and without them it would have never been possible.

It was a true privilege to attend OHM, I can only recommend it! A very healthy way to break out the daily routine for once and enjoy this non-stop party made of a great mix of technology & nature environment. Finally, I leave you with an invitation to another event that shall be pretty much like this due right next year on EMFcamp 2014. I hope to see you there!

More…

• Podcasts and videos available online
• Some of the presentations (audio) are now available online!

The post OHM 2013: An overview appeared first on Portcullis Labs.

• “NetBSD network security vulnerability disclosure” – This talk covers a recently discovered vulnerability in the NetBSD networking code. One for those of you who have an interest in UNIX focused security research, hopefully we’ll see some kernels panic. #imisslsd
• “Decoding memory dumps of mobile phones and navigation systems” – This is a workshop that looks at how to analyse the memory dumps of common mobile phones and other similar devices. Having already performed some work in this space to give our customers a worst case scenario for lost and stolen phones and contributed some of our expertise to the forthcoming OWASP mobile methodologies, we’re wondering if there are any neat tricks we’ve missed
• “Non-signature payload-based intrusion detection” – Talk showing off a non-signature payload-base approach to intrusion detection. We assume it will catch Meterpreter but what about our custom payloads?
• “Trolling the web of trust ” – The web of trust is often considered a strength of PGP however just like Facebook, it can also inform your adversary about the friends you keep. So perhaps you’d like to be friends with key ID 0xF2D755CC? (clue: check out http://pgp.mit.edu/)
• “Rescuing email from the cloud” – Perhaps the flip side to the previous talk, despite the potential for information leakage, PGP presents the only real option for those of you who want to avoid the Internet equivalent of sending all your correspondence as postcards. So what exactly do we do about web mail services that live in the cloud?
• “Hacking your car with open source hardware and software” – We tried to persuade one of our previous employees to let us hack his BMW, he said “no”. This talk promises some new tricks which will benefit next year’s White Hat Rally participants. Best dressed card this year went to our Roving Muppets, but I fully expect that next year, we’ll win it outright!
• “SIM card exploitation” – All over the news at the moment, Karsten Nohl talks about his investigations into Java-based SIMs and the possibilities for remote attacks against mobile phones utilising SMS as an entry point. We’re hoping that it will build on the previous THC research
• “Counter-cryptanalysis: Fire retardant for the next Flame-like attack on MD5 and SHA-1” – Marc Stevens is responsible for some of the more interesting research on viable attacks on SHA-1. This talk will look at some of the state-of-the-art collision attacks on hashing algorithms that are “just around the corner” and how they might be mitigated. We expect this talk to be hot!
• “Even more clipboard fun” – This is all about tricks involving invisible control characters, which whilst unseen on a web page, may when pasted into an xterm yield unexpected command execution.
• “Cisco in the sky with diamonds” – Having previously looked at Huawei, Felix “FX” Lindner pops up to give us the skinny on some recent Cisco research.
• “Low-cost vulnerability research: XSLT fuzzing as a case study” – A talk by Nicolas Grégoire covering his fuzzing of a number of XSLT parsers. If you’re processing XML (and who isn’t these days) then inform yourself on the risks you face
• “Make your own spork” – Seriously, who wouldn’t?

Anyway, the Team will be heading out on Tuesday morning and heading back on Sunday evening. We’re going to be located in the EMF village, so feel free to pop by for a beer if you’re fortunate enough to be attending too.

Editor’s note: A little bird pointed out that I’d spelt Karsten Nohl’s name incorrectly. This has now been fixed.

The post We’re all going on our summer holidays… appeared first on Portcullis Labs.