Our blog returns to surface

After a long hiatus, the blog returns with old and new content, without fully embracing this new era of Blockchain-and-JavaScript-everywhere.

Read article

Why Linux security has failed (for the past 10 years)

A honest look at the present (2009) situation and state of the art of Linux kernel security, and what has failed for almost a decade.

Read article

Runtime binary loading via the dynamic loader on Apple Mac OS X

Read article
Our blog returns to surface
Why Linux security has failed (for the past 10 years)
Runtime binary loading via the dynamic loader on Apple Mac OS X
Our blog returns to surface - Featured Image

Our blog returns to surface

A decade’s worth of resisting the “web 2.0” pandemic We are living through truly amazing times. Barefoot insurgents with 3D printed firearms running around Myanmar, vulnerabilities getting full marketing team makeovers with logos and dedicated websites, the word “opsec” becoming so common place you could hear it from your friendly neighborhood food truck chef, Burning Man going mainstream and the Winklevii chasing would-be Instagram models around Nevada’s largest patch of infertile dirt, the kids we picked on in high school enacting their revenge upon mankind one JavaScript app at a time, old faces from the scene gone all proper and hiding embarrassing tattoos under Brook’s Bros suits, etc, etc, etc.

October 24, 2009 | 9 minutes

Runtime binary loading via the dynamic loader on Apple Mac OS X

An article written by Dan Goodin from The Register was recently published, it mentions a forthcoming presentation by Vincenzo Iozzo, which presents a method to load a binary on runtime, directly from memory, in Mac OS X systems. Here we like to stick to the technical side of things… so let’s get started on explaining how this can be done, in case you aren’t planning to attend Black Hat or just feel particularly curious on the topic!

Apple Mac OS X 10.4 temp_patch_ptrace(): Nonsense in kernel-land

Several software vendors realized, sometime during the 1990-2000 time-frame, that exporting system call tables within kernel address space was a bad idea. This obviously doesn’t mean anything to Red Hat and other GNU/Linux vendors who are happily providing world readable System.map files. Not like anybody needs them, though. Then again, you have to face potential funniness of contradictory measures, like Apple’s own mistakes. This article won’t talk about yet another bug introduced by a Linux developer working at Red Hat (and later silently fixed by another employee of the very same company), but an interesting issue with Mac OS X 10.

Linux Kernel Silent Patching: VMI write_ldt_entry() local privilege escalation

Once again, the Linux kernel developers delight us with their always discreet (meaning: silent, no-advisory, no-warning policy) and wonderful patching practices. Sometime between 2.6.24 and 2.6.25 a patch from a Red Hat developer was committed into the Linux kernel git tree, implementing changes to the VMI interfaces hooking some functions dealing with the GDT and LDT. diff --git a/arch/x86/kernel/vmi_32.c b/arch/x86/kernel/vmi_32.c index 6ca515d..edfb09f 100644 --- a/arch/x86/kernel/vmi_32.c +++ b/arch/x86/kernel/vmi_32.c @@ -235,7 +235,7 @@ static void vmi_write_ldt_entry(struct desc_struct *dt, int entry, const void *desc) { u32 *ldt_entry = (u32 *)desc; - vmi_ops.

Custom shellcode and return-to-libc on Mac OS X (up to 10.5.5)

After some time without any updates coming up, this article will show some techniques and strategies to improve reliability of exploit code in Mac OS X Tiger and Leopard (up to 10.5.5). Specifically, we will look at a technique to aid loading of stager shellcode and evading non-executable stack restrictions. This was hinted at the “OS X Exploits and Defense” book (Elsevier), chapter 7, which we contributed to this year.