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.
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.
Monday, August 04, 2008
Monday, July 21, 2008
MyYearbook
I've been wasting a bunch of time on MyYearbook.com, a MTWWTOSNS (massively time-wasting web-two-oh social-networking site.) If you'd like to descend into madness with me, click here join join for my personal gain:
Be Ryan's Friend
Several interesting aspects to this one, for security people. First, the are many sociological aspects. For example, what happens if you tell people they can't post naked pics? Second, there is a play money currency, which drives everyone's behavior. Finally, they are getting phished left and right from within the site.
And the staff there appears to be so woefully unprepared to deal with it. When I saw the phishing, I thought I might mail their abuse contact info (only email address I found published), and see if they needed info, if I could put them in touch with a takedown group, etc. I got bounces from gmail. Um, your abuse email at your own domain depends on gmail?
The site is absolutely begging for someone to start using XSS. The game model they have basically demands it. For example, your popularity depends on profile views. And I can post a pretty wide range of HTML to someone in about 20 different ways. I haven't tried to see if I can find any XSS. Mostly because I don't trust myself not to abuse it.
But my favorite thing about MyYearbook that I just realized, while sitting in JFK coming back from HOPE. This site is teaching millions of people how to do simple HTML. And nearly half of these people are below average intelligence.
Edutainment, indeed.
Be Ryan's Friend
Several interesting aspects to this one, for security people. First, the are many sociological aspects. For example, what happens if you tell people they can't post naked pics? Second, there is a play money currency, which drives everyone's behavior. Finally, they are getting phished left and right from within the site.
And the staff there appears to be so woefully unprepared to deal with it. When I saw the phishing, I thought I might mail their abuse contact info (only email address I found published), and see if they needed info, if I could put them in touch with a takedown group, etc. I got bounces from gmail. Um, your abuse email at your own domain depends on gmail?
The site is absolutely begging for someone to start using XSS. The game model they have basically demands it. For example, your popularity depends on profile views. And I can post a pretty wide range of HTML to someone in about 20 different ways. I haven't tried to see if I can find any XSS. Mostly because I don't trust myself not to abuse it.
But my favorite thing about MyYearbook that I just realized, while sitting in JFK coming back from HOPE. This site is teaching millions of people how to do simple HTML. And nearly half of these people are below average intelligence.
Edutainment, indeed.
Full RSS Feed
