Archive for November, 2006
Thomas Ptacek | November 30th, 2006 | Filed Under: Gatherings, Uncategorized
It’s downtown, at Houlihan’s, on the corner of Wacker and Michigan, across from the river.
Yes, it’s going to snow tonight. It’s going to snow tomorrow, too, and for the rest of this month and the next one and the next one after that. You live in Chicago, what do you expect? But you’re going to get up tomorrow and drive to work, and you’re going to buy groceries and see Borat and do all sorts of things as well. So you have no excuses.
We’re in the back room. More details at the Chisec page.
And a brief postmortem: excellent meeting! 20+ people, some new faces. Anybody else that showed up, please do comment and tell us how you thought it went.
2 Comments
Thomas Ptacek | November 30th, 2006 | Filed Under: Apple, New Findings, Uncategorized
Alastair Houghton, past Matasano sniping target, on LMH’s DMG finding:
Because of this, on the second pass through this loop, vm_fault() gets
called with address set to point to a non-aligned address inside the
first buffer held by the IODeblocker.
Note that it isn’t possible for it to point outside of this buffer,
because the segment length, held in segLen has to be in the range 0x1
≤ segLen ≤ 0x1ff as it’s set up by the IODeblocker to buffer the
misaligned part at the beginning of the read. The buffer itself is
larger than that, so there’s no chance of any mischief because the
ability of a potential attacker to set the address at which vm_fault()
gets called is extremely restricted.
Anyway, it is the call to vm_fault() with a non-aligned address that
is causing the kernel panic.
So, what have we learned:
It is not a memory overwrite bug.
It is not exploitable, except in that you can kernel panic a machine if you can persuade a user to double-click a damaged dmg file.
It is not, therefore, possible to use this bug for privilege elevation or to execute arbitrary code in the kernel.
Sometimes you pick on a Mac Zealot and they turn around and kick your
ass for it. That’s what happened here. Alastair’s analysis is
excellent. Hopefully he’ll do this again for other complicated Mac
findings.
I apologize for conflating Alastair with Gruber. =) No, wait, I simply apologize to Alastair. Sorry.
An important takeaway point from this: DMGs are a high-risk
feature, and one that OS X has substantially greater exposure to than
other operating systems. What we had here was a flaw in the DMG loader
code. Compared to the underlying filesystem code that runs when the
DMG header itself is valid, the DMG code is simple stuff. Long story
short: expect more DMG-style problems to come.
7 Comments
Thomas Ptacek | November 30th, 2006 | Filed Under: Bitching About Protocols, Reversing, Uncategorized
‘Tis the season, apparently. Cool new project and excellent blog post
from libnids author and Eastern European reversing psychopath Rafal
Wojtczuk, now at MCAF’s AVERT labs. He’s announced UMSS, the User Mode
Single-Stepper, a tool for tracing the execution of Win32
binaries.
Refresher: single-stepping stops a program after each individual CPU
instruction, usually to record them. It’s usually done with a
debugger; on Intel, you do it by setting the “trap flag”, which tells
the CPU to generate exceptions after each instruction.
The problem here is, each instruction traps to the kernel, which then
transfers control to another process, which then transfers back to the
kernel to find out what happened. A single user/kernel (u/k)
transition is expensive: network programmers, who execute thousands of
instructions between I/O operations, still try to minimize
them. Debugger single-stepping involves multiple u/k context switches
per instruction. It’s just nightmarishly slow.
Rafal’s project speeds this up by 2 orders of magnitude by single
stepping entirely in userland. How he does it is, he continuously
rewrites the “next” instruction on the fly to transfer control to a
handler function.
This is similar to what Detours does in that Rafal is swapping out
instructions with handler jumps. But Detours only instruments the
prologues of each function. UMSS instruments every instruction, on the
fly. This is tricky, because to do that for each instruction, you have
to know where the next instruction is. It’s not always “the next
instruction in memory”, because of jumps. It’s not always “the target
of a jump”, because jumps are conditional. It’s not always even
possible to look at an instruction and know the jump target, because
jumps can be indirected through registers.
UMSS solves this problem in two ways:
it uses an embedded disassembler to decode jumps with static targets, and peeks at the condition flags to figure out whether jumps will be taken.
it has a simple and clever heuristic for indirected jumps: just switch
back to kernel-assisted debugging for that instruction. The
overwhelming majority of the instruction stream doesn’t need it, so
you still get the huge speedup.
Why is this stuff important? To be honest, I don’t know. The “state of
the art” in tracing programs right now is in instrumenting basic
blocks, which are the ~10-20 instruction chunks that functions are
composed of. For reversing purposes, this level of detail is usually
more than enough. Clearly for malware research, where code is
deliberately designed to be unclear, instruction-by-instruction detail
is critical. I’d love for someone to tell me how I could exploit fast
single-stepping to get a different project done.
The bigger story is the apparent renaissance we’re experiencing in
binary program manipulation. 7 years ago, technology like Detours,
PaiMei, and UMSS would have been the closely-guarded crown jewels of
security companies. Now they’re free side-projects.
7 Comments
Dino Dai Zovi | November 29th, 2006 | Filed Under: Disclosure, Industry Punditry
First comes the vulnerability. Then comes the fame. And then the women. Finding vulnerabilities is sexy and makes great news these days. Unfortunately, this is attracting the type of vulnerability finders that may only be in it for the fame. In a time long ago and a land far away, the only people who discovered vulnerabilities either were doing so to improve products or take advantage of them for any number of reasons. That necessitated finding the actual cause of the vulnerability and/or method of exploiting it. Now, however, when fame is the only goal, neither of these is actually necessary. One may just find a crash due to a null pointer dereference, say “Risk: High, code execution”, and go straight to the recognition. Over the years, we have seen plenty of bugs and bug classes that were not thought to be exploitable later proven to be so by some very ingenious ways. Now we know better. Unfortunately, we have gone so far in our exploitability paranoia that we assume that all NULL pointer dereferences can lead to code execution. That perception is misguided for a number of reasons.
Assuming that vulnerabilities may be exploited in the future by yet-to-be-discovered means is not unjustified, but it must be tempered with some analysis of the specific vulnerability that has been discovered. Some very smart and talented people have advanced the state of the art of exploitation. Three that come to mind are Solar Designer’s JPEG exploit, Gobbles’ Apache exploit, and Skywing and Skape’s Exploiting the Otherwise Non-Exploitable on Windows paper. SD’s BUGTRAQ post clearly and eloquently brought heap structure corruption exploits into the mainstream. Also note how even though no exploit was provided, he did not just throw up a stack trace and register dump and say, “Code execution!”, but instead explained just how it was possible leaving no doubts as to whether the vulnerability was exploitable. Similarly, Gobbles laid down the law with apache_scalp.c proving that the Apache chunked encoding bug was, in fact, quite exploitable and exploited in the real world.
Skywing and Skape’s paper deserves a little more discussion. Most people understand their discovery to be a technique to exploit NULL pointer dereferences in Internet Explorer. They discovered that by loading and unloading certain COM objects out of order, they can leave the Unhandled Exception Filter function pointer dangling. Then, whenever the browser crashes (NULL pointer deref or any other crash), the dangling UEF pointer will be used. If you use javascript to populate the heap with controlled values, you can often control the function pointer that will be used. There are three ingredients to this type of exploit: dangling UEF, heap population, and a crash. The dangling UEF pointer is actually the vulnerability, and Microsoft patched it. Controlled heap population is also not possible in every application. So under no circumstances should the takeaway from this paper be, “NULL pointer dereferences are exploitable now.”
What is the difference between a software penetration tester and a QA tester and why do you pay more money to the former? Both make software crash. The penetration tester, however, provides value after the crash. They identify the risk of the vulnerability by identifying where and how the vulnerability is triggered and whether it is exploitable (and if so, how reliably). They should understand what types of vulnerabilities are exploitable by currently known methods and what types are highly unlikely to be exploitable. Developers and vendors need to prioritize security issues among other development needs and security is going to be ignored when risk is blown out of proportion. A good penetration tester provides this analysis, giving clients verified, reproducible vulnerabilities that may be appropriately prioritized.
Therein lies the difference between vulnerability sportsmen and vulnerability hunters. Sportsmen are out to get the biggest trophy for their wall, so they hunt endangered species with bazookas. After the kill, they are done. A hunter respects the hunted, learns about it, and eats it. In this metaphor, that means identifying the cause of the vulnerability and even exploiting it. Sportsmen go quail hunting blitzed and blast their friend in the face with a shotgun. Hunters track prey silently through the forest and kill cleanly with a bow and arrow. Vulnerability Sportsmen fuzz blindly and don’t even sort out the bodies, but instead print out stacktraces, register dumps, disassembly (in open source products, no less) and other random data that doesn’t even identify the vulnerability. The true hunter finds the code that is the cause, identifies how much control the attacker has, whether it may be exploited, and proves it if there may be any doubt.
In the current security climate where posting of working exploit code is frowned upon, there needs to be an alternate mechanism that provides accountability and transparency in security vulnerability reporting. Otherwise we are left with the “he said, she said” debate between vendors and researchers where neither party shows their cards and the validity of all independent security research is harmed in the process. A trusted third party vulnerability verifier or broker with actual vulnerability exploitation expertise would help rescue the process of independent vulnerability disclosure. That needed service is hopefully not too far away.
13 Comments
Thomas Ptacek | November 28th, 2006 | Filed Under: Gatherings, Uncategorized
Oliver likes to keep us on our toes, and we like to disappoint him by taking 48 hours to post updates to our blog, so without further ado: show up at BeanSec tomorrow, buy one (1) drink (domestic only), and invoice Matasano.
We’re good for it. I promise.
There are literally 19,456 security professions in the Boston area. If only 1% showed up, that’s a huge meeting! Join the fun: 567 Mass Ave at Enormous Room, 6:00PM.
4 Comments
Thomas Ptacek | November 28th, 2006 | Filed Under: Gatherings, Uncategorized
See the website for more details. It’s right smack in the middle of downtown Chicago, where the river meets Michigan Ave. As always, there’s no need to RSVP, no memberships are involved, and it’s only slightly likely that I’ll give a long-winded speech about some trivial security topic that’s been bugging me this week.
If you’re in Chicago and you work in security you have no excuses. I expect to see you there. Attendance will be taken!
1 Comment
Thomas Ptacek | November 28th, 2006 | Filed Under: Industry Punditry, Uncategorized
Richard Steinnon, formerly of Gartner, then of Webroot, then of “indie
analyst” IT-Harvest, is now the VP of Marketing at mainstream “UTM”
appliance vendor Fortinet.
Amrit Williams, also formerly of Gartner covering security management,
is now the CTO of patch and systems management up-and-comer BigFix.
We wish both of them luck, but note affectionately that there’s a
pattern here: the “escape hatch” from analyst firms to high-level
marketing positions at vendors. It’s hard to avoid the impression that
analyst shops are farm teams (or, more generously, bullpens) for
product marketing.
This is a conflict of interest. How does one render objective judgement
on companies while at the same time keeping their options open for
future employment at them?
I invite our analyst readership to comment, or, even better, make
their position clear.
For my part: Matasano makes no claims to objectivity.
22 Comments
Dino Dai Zovi | November 28th, 2006 | Filed Under: Uncategorized
A few weeks ago, I was lucky enough to be invited for an interview on the computer security podcast, Sploitcast. The host, Matt Hillman, and I got to chat about VM rootkits, OS X security, attacking Wi-Fi clients, and
—
wait for it…wait for it…
—
vulnerability disclosure. As a teaser, the disclosure discussion is not the same old one but instead regarding the need for trusted third party vulnerability verifiers in the age of responsible disclosure. Give it a listen: Sploitcast #16.
1 Comment
Thomas Ptacek | November 27th, 2006 | Filed Under: Reversing, Uncategorized
Last week I wrote about the INT 3 trick for bringing a service up
under a debugger, at initialization, without using gflags or editing
the registry. Recall that without source code, Windows services are a
pain to debug, wanting to run from the Service Controller instead of
the command line.
The INT 3 trick is a single-byte binary patch to trap to the
debugger. This is great if all you need is to get the service
initialization code up under Olly or windbag[*]. But I’m reversing some
silly (and convoluted) crypto code. I want PaiMei.
Trapping to the debugger isn’t going to help me, because PaiMei wants
to do its own (manual) attach; it’s not a Just-in-Time
debugger. Trouble is, services takes milliseconds to start, and I
can’t click that fast.
Now I have a lot of options.
The code I’m looking for is isolated in a single DLL. Can I just
pull it into Python through ctypes? Ctypes is a work of art; it’s
a pitch-perfect foreign-function interface for Python, which means
makes C DLL’s directly callable by Python code without any heinous
SWIG-style situps. Using ctypes I could just write a little
wrapper program for my DLL that was not itself a service, and use
PaiMei on that.
Unfortunately, this is a C++ DLL, and ctypes does not play well
with C++ at all. The name-mangling problem is easy to get around,
but the “defining classes and locating vtables” problem isn’t,
especially when I don’t know what the class definitions are.
Since I’m after a DLL, I can patch the DLL import table,
in the service executable, redirecting calls to an interceptor
function. Simplest case: just sleep 30 seconds and then hand
control over to the real function. My excuse for not going this
route: it didn’t occur to me until I started writing this post.
I can use Detours. Damn, Detours is slick. It binary-patches
executables on the fly to intercept arbitrary Win32 function
calls. It does that by:
Adding a new section to the PE image and redirecting the
DLL import table to it. Detours uses this to hold dynamically
generated code and data payloads as well as to load new DLLs
into the target program.
Binary patching the functions to be detoured.
The simplest way to intercept a function call is to find its
call site (by scanning through binary code looking for
direct CALL instructions with your target function as an
operand). But that requires tons of little binary patches
and misses indirect calls (ie, function pointers). So
Detours does something different:
Detours locates the target function and replaces the first
few instructions with a JMP into the interceptor function
(which you presumably loaded as a DLL when Detours attached).
It takes the original instructions from the JMP site and
moves them to a trampoline. When your interceptor is done,
control is handed to the trampoline, which executes the
original instructions Detours patched away. Then control is
handed back to the target function.
Detours is a Microsoft Research project. You can download it for
free. Damn, is Detours ever slick. It comes with a “withdll.exe”
function that you can use to throw arbitrary DLLs into arbitrary
Windows programs, and a whole bunch of little sample DLLs, such as
“trace all WinAPI calls”. Damn, is Detours ever slick. I really
have no reason to use anything else. Except… I need to set up
a Windows C/C++ build environment on my target machine to use it.
I’d rather eat a bug. Bringing us to option 4:
I can do what Detours does by hand. After all, I only need to
insert one Sleep() call.
This is what I actually wound up doing. To pull it off, I used
HT, an open-source binary editor. Where has this program been
all my life? For mainstream platforms, HT does the 80% of IDA
Pro I actually care about, and adds inline hex/assembly editing.
So, using HT, here’s “Back Alley Detour”:
Open the DLL in HT.
Find the function I want to insert the Sleep in.
NOP out enough instructions to make room for a 5-byte
unconditional JMP.
Set a label for the following instruction, “resume”.
Find a nice long patch of debug output in a DLL rdata
section. Set a label for the first byte, “egg”.
Go back to my NOPs, hit CTR-A, and enter “JMP egg”.
Go back to my egg, and:
push eax
push ecx
push edx
mov eax, 20000
push eax
call [42330h] ; &KERNEL32.Sleep
pop edx
pop ecx
pop eax
; instructions patched out of original function
jmp resume
Save. Start the service. Attach PaiMei to it. Read RSS
feeds for 14 seconds.
I want to do more with Detours. Damn, is Detours ever slick. But for
very simple interventions, installing the VC++ compiler on a test lab
box is overkill.
[*] Outside of the kernel, Olly rules all over windbg.
8 Comments
Dave G. | November 24th, 2006 | Filed Under: Malware
Tis the season! Looks like the same fellow who did this chose Thanksgiving Day to strike again. Good timing from an attacker perspective. This was sent to my Yahoo IM:
http://www.geocities.com/isyourfriendneartoyou08/ Find your match
And then it:
- presents a Yahoo! Photos page
- steals credentials on submit
- sends it to: http://www2.fiberbit.net/form/mailto.cgi
- who mails it to “sanchopansas@gmail.com”
- redirects the user to their own Yahoo Photo’s page
- logs into Yahoo IM as the unfortunate sap
- sends the URL to everyone on their buddy list
Have (or hope you had) a Happy Thanksgiving!
2 Comments
