Blog

Viewing posts from 2008

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

Posted by: Subreption LLC in Security Apple 3 years, 6 months ago Several software vendors realized, sometime during the 1990-2000 timeframe, 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.4 systems on PowerPC. read more / Comments

Linux Kernel Silent Patching: VMI write_ldt_entry() privilege escalation

Posted by: Subreption LLC in Linux Security Critiques 3 years, 6 months ago Once again, the Linux kernel developers delight us with their always discreet (read: 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. Tags: linux
read more / Comments

Custom shellcode and return-to-libc on Mac OS X

Posted by: Subreption LLC in Security Apple Research & Development 3 years, 7 months ago 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 I wrote earlier this year (co-authored the book with Kevin Finisterre). read more / Comments

Marshal and Native API bridging on Microsoft Windows (NT)

Posted by: Subreption LLC in General Microsoft Software Development 3 years, 8 months ago Marshal and Native API bridging on Microsoft Windows (NT) read more / Comments

Linux kernel developers silently patching issues? No way!

Posted by: Subreption LLC in Linux Security Critiques 3 years, 10 months ago Alright, this might be the first article on the "Silent Patches" series, starting today and possibly lasting... forever. So, let's get to the business. Brad "spender" Spengler is pissed, and that's already a bad thing for the many people that knowingly or not, take advantage of his work and that from the guy or guys behind PaX, to be referred as The PaX Team, or Those Smart Guys Teaching Security On LKML. spender and the PaX Team have possibly contributed the most important advances in proactive defense technology for the past decade. ASLR was there before it became a marketing buzzword, NX and memory protections enforcement existed way before Red Hat pushed ExecShield to the Linux kernel and TCP & UDP source port randomization have been known for a while (even though now they seem to be the world's new internet superheroes with all this DNS the-end-is-nigh media frenzy). If you have used grsecurity in the past few years, you've used what Microsoft, Apple and Red Hat pretended to market as brand new technology baked in their very own development cubicles. The story now is how the Linux kernel developers managed to absolutely and irremediably piss off the very same people that fed them with security research and technology that really worked as expected. The very same people that have patched upstream vulnerabilities in their "third-party patches". Back in 2005 (see [1]) this was already happening. The fact that now we have a handy git interface where we can retrieve commit logs without difficulty just helps to pinpoint the silently patched issues and identify potentially hot issues. Our take on this fracas is that spender and the PaX Team are rock-solid consistent with their arguments, and that the Linux kernel development people should definitely change their alleged full-disclosure policy text with one more accurate accordingto their true practices. read more / Comments

  • < Previous
  • 1
  • Next >