Sunday, November 29, 2009

Fixer-Upper

Continued from Welcome Home

The sunlight disappeared again, and he assumed he was wheeled into a building. He felt several turns and a jolt that he thought must have been his gurney being shoved through a swinging door. He came to a halt, and another bright light painted his face sheet. Very artificial light.

The sheet was pulled away. More surgical masks this time. There was an overhead light on an articulated arm. Buzzed, muffled voices, one of the masked individuals gestured at the light to another. The latter grabbed a handle on the side of the light with a gloved hand, and aimed it directly into his face, forcing him to squeeze his eyes closed.

He felt latex-covered fingers prodding his head and neck. A shadow fell over his face, and he opened his eyes to see a masked face with plastic glasses leaning over his, looking into his face. He assumed the face belonged to a surgeon. The mask, glasses, head cover, gown, mostly blue paper said medical to him. The surgeon's head was blocking the flow of light. He could see the surgeon's jaw moving behind the mask, looking at him, talking to him, but all he could hear was the buzzing, muffled sounds. The surgeon gave up, and shook his head "no" to someone beside him.

The head withdrew and the bright light shut his eyes again. The probing fingers returned, concentrating on his neck. They pressed hard, causing him to flinch from the pressure. Down the side of his neck they poked, until they were partway down his shoulders, where the poking was replaced by a slight pressure or tugging. This was repeated multiple times on each side. Poking hard enough to get a reaction higher up on his neck, and then gentle pressure as they went further down his shoulders.

He felt fingers at his ears, pulling them in different directions from the outside. He didn't feel them extract whatever had been shoved into his ears that kept him from hearing, but they inserted something cold and hard into his right ear. His ear was still numb and the sound was muffled, when he felt a sudden stabbing pain in his ear. He instinctively tried to jerk, but the movement was truncated by the screws that still held his head in place. It didn't stop the stars of pain from lighting up his closed eyes.

While he was concentrating on stilling himself, the intensity of the light on his face abated. He opened his eyes and blinked away the tears. Looking up, he saw the light was aimed further down his body. He tried to follow with his eyes, but he was lying flat, and there were tubes at his nose and mouth partially blocking his view. He could see the surgeon's side near his face. The surgeon was bent over his body.

He watched the surgeon take several scalpels in a row, and bend low over him each time. Each time, he would place the bloody scalpel on a tray. He couldn't feel any pain. He realized that he must have been heavily drugged most of the time for days, which is why he couldn't move and was so foggy.

He didn't have any memory of his capture or injuries. He didn't know who had him, or if they were the ones who did this to him. He had eliminated the possibility that it was just medical personnel. Hospitals don't use military transports, and they don't keep you moving for days before they operate. Unless he dreamed all of that. Unless he'd already received some treatment. But he couldn't have dreamed all of it. He knew they had found him.

Next the surgeon grabbed some kind of big pliers or clamp. He saw that they opened when the handles were squeezed as the surgeon flexed them. He must have left them in place, because he stood up empty handed. He was handed what looked almost like a soldering gun, but when the surgeon pulled the trigger, he could see a small blade vibrate at the end, almost like a tiny skillsaw.

His eyes went wide when he realized that it was a sternum saw, and that his chest was being cut open. His eyes went wide, and he tried to thrash. The panic made him able to ignore the pain as he writhed and his eyes rolled in his skull. The surgeon stopped momentarily and motioned in his direction with a tilt of his head. From behind, he felt a needle insert into his neck. A slight burning spread up the blood vessel in his neck. The needle was withdrawn, and they unceremoniously dropped the sheet back over his head box.

As he sank down below consciousness, he thought "why are they keeping me alive?"

Monday, November 23, 2009

Welcome Home

I thought I might experiment with some serialized fiction on my blog. I'm trying a slightly different style. I'm going to attempt to be a little gory and disturbing so if that bothers you, fair warning. I'll have a tag for these posts later.

-- end author's note

The jolt from the helicopter landing shook him into awareness. Another stab of lightning shot through his head and made his vision go white. Water leaked from behind his eyelids, squeezed tight from the pain. He knew it was a helicopter from the vibrations of the rotors. He had spent a little time on helicopters in his 20's.

He couldn't tell if it had been days, or a week, or more. He spent much of the time unconscious from pain or drugs. Or not being able to tell the difference between real and imagined. Rarely, he could catch a blurry glimpse of the inside of an ambulance or plane when they would remove his head covering to work on him. If he didn't have an overhead light blinding him.

Every face he caught sight of during this time was covered with a mask. These ranged from baby-blue or white surgical masks, to Army green and SWAT black gas masks.

He could tell words were being spoken all around him, but was unable to understand them. Not because they weren't English. He thought they were, from the rhythms of the words. He couldn't understand because they had shoved something in his ears days ago and left it there. Words came to him as a buzzing, scratchy sound. The loudest thing in his head was a constant tone, like an old modem trying to sync. He could "hear" the helicopter blades as a vibration in his skull. His ears hurt, but the pain level barely registered above the symphony of hurt that was his head.

Frightening to him, it was only his head that hurt. He had been able to see down his body twice. Each time, covered and strapped down. The whole time he was in custody, they had him strapped down to a gurney. He thought he had moved his arms and legs a few times while strapped down. Simultaneously light and drug-deadened.

Tubes ran through his mouth and nose. A machine pumped air in and out of him. He could feel temperatures and pulses slide through the tubes. His head was caged in a scaffold of bars, forming a box. At odd angles to the box were long, spiked screws that drilled directly into his skull, immobilizing him. The entire box was draped with a sheet.

Shadows across the sheet indicated that there were men at the sides of his gurney. It started to shake, and then it felt like he was rolling. He imagined fabric straps being release from the floor and walls and his wheels being unlocked. He was rolled towards what must be the helicopter door, and hoisted by his pall bearers. He floated through the air briefly until his wheels made contact with ground again. There was a qualitative difference between rolling on the steel floor of a vehicle and the rough pavement or concrete he rolled on now.

As he rolled, the shadow line suddenly crossed his sheet, and bright light illuminated his covering. He could immediately tell the sunlight from the artificial lights he'd been under. The warmth and color were unmistakable.

It was the last time he would ever see sunlight with his own eyes.

Monday, May 11, 2009

Concept Art

Some concept art for a project I'm working on with my oldest son. He's the artist, not I.












The Mac Hacker's Handbook



The Mac Hacker's Handbook is the best reference for Mac-specific attack information that I have found. At 368 pages, it may appear small compared to the typical 750+ page security tome. That's because the authors have done a near-perfect job of sticking to the topic at hand, the Mac. The authors do not succumb to the usual temptation to try and teach assembly language or reverse engineering. Rather, they do an excellent job touching on those topics in an OS X context, and assume the reader has a little background in that area already, or can otherwise keep up. I have done some limited research into the areas of Mac malware and process injection in the past. This book has done a fantastic job of filling in many holes in my knowledge that I hadn't been able to take care of before. Plus, it introduced me to a number of Mac-specific security features I wasn't aware of before. Highly recommended for anyone interested in Mac security.

Detailed commentary follows.

The authors Charlie Miller and Dino Dai Zovi have impressed me on several levels.

A couple of years ago, I did a presentation of Mac malware, where I researched some similar areas on my own. The purpose of my talk was to demonstrate that the privilege separation on a typical single-user OS X box made no difference, because an attacker could do everything they need from user mode.

My skills are somewhere between beginner and intermediate in the areas of programming, reverse engineering, vulnerability research and exploit writing. With a lot of work, I was able to create a very crude keyboard sniffer by attaching a library to launched processes. In one chapter (chapter 11), this book spelled out everything I needed to know and more. And implements several useful injected components in a much more flexible way than I was able to. I could have really used this information then.

I ran across many of the same libraries and examples that the authors reference in the book. However, they were mostly code examples with no context, intended to be groked by hard-core Mac programmers. Here, they are presented in an actual understandable way, building on examples as they go. It makes a huge difference. The level of writing meshed perfectly with my past knowledge and filled in the holes I had. I have an advantage over a rank beginner, but I suspect they have reached as wide an audience as is possible with their writing.

They do this consistently throughout the book. And this is what really made this an excellent book for me, was the actual writing. You'll have to excuse me if I geek out a little bit on this topic, but I've written a few technical books myself, and I have a great appreciation for how hard it is to do this well.

There are many traps one can fall into when writing a book like this. A lot of the topics are circular. As in, it's difficult to pick a sane order to follow, and not repeat a lot of information. There's always a temptation to try and show off advanced topics, and not adequately cover the intro material. It's easy to get lazy and not put the time into explaining a concept, assuming everyone knows it. Authors sometimes dump a lot of pictures and code on the reader for length.

These authors fell for none of these. The ordering of topics and advancing difficulty seem ideal. Code is almost uniformly useful and well-documented. They don't beat you over the head with example after example for the same topic. Rather than attempting to include a complete PowerPC and x86 instruction reference, they give you the minimum set of instructions that they used. The pacing was great. I was neither bored reading things I knew, nor unable to keep up with the material (until I struggled slightly to absorb the last chapter or two.)

Production values are good. The price is great, the length is very appropriate. Editing is good. (Not perfect; I spotted a dozen very minor typos. But then, I can't turn off my internal proofreader anymore, you're unlikely to notice most if any of those.)

There are other minor things to appreciate if you've been around vulnerabilities and exploits for a while. I feel like they did a great job explaining heap exploitation, compared to other attempts I've read. I very much enjoyed the little bits of history when they discuss who pioneered a particular technique. Most of Dino's code has a date in the comments, so you have some idea what was known at the time.

I'd go so far as to say that this book really is a general book about how to find and exploit vulnerabilities, using the Mac as your research platform. And it turns out that the Mac is a great place to learn.

Thursday, April 02, 2009

Hey! You! Get off of that cloud!

Or Microsoft won't support you.

We've had an interesting several days dealing with Microsoft at work. BigFix recently signed an Enterprise Agreement with Microsoft, where we committed to X licenses of the workstation OS, and put a number of other things under Select Agreement, including Server OSes, Exchange, SQL Server, MSDN subscriptions, and so on. This came with a few free support calls.

Our OS X and iPhone users (in particular, our CEO) have been anxious to get on Exchange 2007 for the rumored improved Entourage and iPhone support around calendars. So when our CFO wrote the large (for us) check to Microsoft, the IT Team committed to implementing Exchange 2007 in an aggressive time frame. Currently, we're using Exchange and OWA 2003.

Doing some research, it looked like the best option was to build new Exchange and OWA machines and migrate mailboxes. It also looks like the best OS choice is Windows 2003 Server Enterprise 64-bit. We read some documents that indicate Exchange 2007 isn't fully supported on 32-bit Server, and has only just been qualified on Server 2008.

We put Exchange itself on physical hardware for performance reasons. It's probably not really necessary, but we're being conservative. We used a Dell 2850 with about 1TB of disk and 32GB of RAM that was a VMWare ESX server until I replaced it with an even larger Dell R900. It's running Windows Server 2003 Enterprise R2 64-bit. The OWA machine doesn't need any particular performance characteristics though, so we decided to put it on a VM. It's on the same OS. No problems running 64-bit guests, by the way. We do it all the time.

Like many companies, we're trying to virtualize a lot of our infrastructure. We've made a fairly large investment in VMWare's enterprise products for a company our size, especially in our Engineering organization. I won't get into the benefits here, but for us they are substantial, and our entire disaster recovery plan is tied to VMWare ESX.

Things were on schedule with the Exchange 2007 configuration. In the interest of time, we had made one support call to Microsoft for install problems on the physical hardware. It burned the equivalent of $299, but for our schedule, it was easily worth it. Exchange was working.

We ran into a second issue with OWA 2007. My sysadmin was having trouble getting Outlook Anywhere to work correctly with Outlook 2003 and Entourage. He called again. This time, while the Microsoft support engineer was remote into our OWA server, he saw VMWare Tools in the Add/Remove Programs list. He asked, and we said yeah, it's a VM.

He said he could not support us, closed the ticket, and advised us to rebuild on physical hardware and call back. The support engineer also said that if we had had Premier Support, that he could "Look into it." He cited this article: http://support.microsoft.com/kb/897615

I'll summarize it: Microsoft only supports virtualized Windows and MS apps if you use Microsoft virtualization software.

That had never occurred to any of us in the IT department. That policy is so ridiculous as to defy belief.

I complained into the air on Twitter. I got two categories of response: Lie to Microsoft Support, and No, they do support it. It's called the SVVP.

Sure, we're willing to lie to support. We just didn't know it was necessary, and we got caught this time.

By the way, I'm going to jump ahead in the story for a moment and say that yes, we did rebuild OWA on physical hardware and call back. And it turns out that the problem was on the Exchange server, NOT the OWA server. So no, it's not possible that VMWare was a factor, and yes, we did waste days and slipped our schedule for no good reason. I say this mostly to save you the trouble of trying to fix my technical problem, it's already done.

And of course, that's not the real issue.

During these several days while my sysadmin gave up and build a physical box to appease Microsoft Support, the rest of us were complaining bitterly to our Microsoft sales rep. We still could not believe that they really intended to have that as a policy. He insists that they did. He knows, because he has had "lots of customers complain about it."

What about the SVVP, I asked my sales rep? Both a Microsoft employee and a VMWare employee pointed out to me on Twitter that ESX IS supported. Nope, my sales rep says that's only for the Windows OS itself.

But wait, the VMWare guy pointed out to me that Exchange on VM is specifically covered under the SVVP. Surely this means I'm good, right? This is just a case of Microsoft Support not being up on the latest Microsoft policies?

Nope. That article only covers Exchange 2007 SP1 (good) on SVVP virtualization software (good) on Windows Server 2008 (bad, I'm using Server 2003.)

So yes, they STILL turned me down for support on ESX. But they would support all of it if I was using Hyper-V.

This is far worse than my little problem not being handled. This would seem to indicate that Microsoft intends to qualify every single app they produce as being covered on VMWare or not. And only the versions that they feel like. And only if it's on a Windows version they want to cover.

So the latest set of articles on how to tune SQL Server 2005 on ESX? Forget it. It's not supported.

It's really hard to not immediately leap to accusing Microsoft of more anticompetitive behavior and vendor lock-in for their own virtualization technology.

Does Microsoft qualify every individual app on the hardware in the supported hardware list? Of course not. If the OS works, the apps should work. That is the basic job of the OS, yes? To abstract the hardware for the apps? So if Microsoft has qualified Windows 2003 on ESX, why should they decline to support OWA on it?

Is there an Exchange 2007 SP1 supported hardware list somewhere I'm not aware of?

At my most generous, I can assume that Microsoft Support is just not aware of Microsoft's own policies on this topic. And Microsoft Sales isn't either. My rep still says he can't help me. I can even see wanting to qualify Microsoft OSes on ESX "hardware", just like they would on Dell or HP. (Though when is the last time Microsoft Support even ASKED you what hardware you're running on?)

But to try and take a policy that every app needs to be qualified individually, down to the service pack level? Unless you're on Microsoft's virtualization technology?

That's just quite possibly criminal.